diff on dirs?

Hi,

I just noticed a flaw in our diff() interfaces: It seems
that while we
don't explicitly forbid it its impossible to use them to
create a
recursive diff(). So the user of the interfaces has a
relatively hard
time to get a diff for a whole directory or even working
copy as he has
to iterate the whole tree.

I don't think thats reasonable to request from the interface
users, so
I think we need some extensions there - or don't we?
Currently VcsDiff
has a left and right hand side, each providing a QString and
a unified
diff. 

The diff is able to carry recursive information, but we
don't have a way
to produce enough information for "left" and
"right" side of the diff. 

On a quick thought: QMap<QVariant,QString> for those,
mapping file
locations (either local or remote) into content strings
might be enough.
(and QByteArray versions for the binary)
Any other ideas?

Andreas

-- 
Don't Worry, Be Happy.
		-- Meher Baba

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Andreas Pakulat wrote:
> [snip preamble about recursive diff]
> The diff is able to carry recursive information, but we
don't have a way
> to produce enough information for "left" and
"right" side of the diff. 
> 
> On a quick thought: QMap<QVariant,QString> for
those, mapping file
> locations (either local or remote) into content strings
might be enough.
> (and QByteArray versions for the binary)

That sounds about right.

(hehe... .sig seems appropriate)

-- 
Matthew
"It's impossible! But... do-able."
   -- Robert MacDougal (Sean Connery, Entrapment)


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 08 October 2007 04:49:02 pm Andreas Pakulat
wrote:
> Hi,
>
> I just noticed a flaw in our diff() interfaces: It
seems that while we
> don't explicitly forbid it its impossible to use them
to create a
> recursive diff(). So the user of the interfaces has a
relatively hard
> time to get a diff for a whole directory or even
working copy as he has
> to iterate the whole tree.
>
> I don't think thats reasonable to request from the
interface users, so
> I think we need some extensions there - or don't we? 

We do. 

> Currently VcsDiff 
> has a left and right hand side, each providing a
QString and a unified
> diff.
>
> The diff is able to carry recursive information, but we
don't have a way
> to produce enough information for "left" and
"right" side of the diff.
>
> On a quick thought: QMap<QVariant,QString> for
those, mapping file
> locations (either local or remote) into content strings
might be enough.
> (and QByteArray versions for the binary)
> Any other ideas?
>

Nope. I think that sounds fine.
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 08.10.07 17:07:24, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > [snip preamble about recursive diff]
> > The diff is able to carry recursive information,
but we don't have a way
> > to produce enough information for "left"
and "right" side of the diff. 
> > 
> > On a quick thought: QMap<QVariant,QString>
for those, mapping file
> > locations (either local or remote) into content
strings might be enough.
> > (and QByteArray versions for the binary)
> 
> That sounds about right.

Unfortunately its not as easy as that :( QVariant provides
no qHash and
no operator< so you can't use it as a key in a QMap or
QHash.

The problem we have is that we use KUrl for
client-side-files and
QString for server-side-locations. So QVariant seemed
reasonable to have
only 1 method that can take either of the two.

Possible solutions:

a) Always use QString, this is a breakup with other parts of
the
platform API which use KUrl
b) A new Location type that has operator < or a qHash
function and
allows to retrieve either a string or a url and also knows
how it was
constructed (i.e. wether it is a repo or local location)
c) Only use QString in VcsDiff and store the information
wether thats
repo location or local locations in the VcsDiff object as
well

Personally I'd prefer b) I think, with changing all
QVariant's to
Location in the API's but leaving KUrl/QString API's as they
are now.

Oh and of course the name of the Location type is subject to
discussion
as well, if somebody has a better idea...

Andreas

-- 
You may be infinitely smaller than some things, but you're
infinitely
larger than others.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 08 October 2007 08:06:27 pm Andreas Pakulat
wrote:
> On 08.10.07 17:07:24, Matthew Woehlke wrote:
> > Andreas Pakulat wrote:
> > > [snip preamble about recursive diff]
> > > The diff is able to carry recursive
information, but we don't have a
> > > way to produce enough information for
"left" and "right" side of the
> > > diff.
> > >
> > > On a quick thought:
QMap<QVariant,QString> for those, mapping file
> > > locations (either local or remote) into
content strings might be
> > > enough. (and QByteArray versions for the
binary)
> >
> > That sounds about right.
>
> Unfortunately its not as easy as that :( QVariant
provides no qHash and
> no operator< so you can't use it as a key in a QMap
or QHash.
>
> The problem we have is that we use KUrl for
client-side-files and
> QString for server-side-locations. So QVariant seemed
reasonable to have
> only 1 method that can take either of the two.
>
> Possible solutions:
>
> a) Always use QString, this is a breakup with other
parts of the
> platform API which use KUrl
> b) A new Location type that has operator < or a
qHash function and
> allows to retrieve either a string or a url and also
knows how it was
> constructed (i.e. wether it is a repo or local
location)
> c) Only use QString in VcsDiff and store the
information wether thats
> repo location or local locations in the VcsDiff object
as well
>
> Personally I'd prefer b) I think, with changing all
QVariant's to
> Location in the API's but leaving KUrl/QString API's as
they are now.
>
> Oh and of course the name of the Location type is
subject to discussion
> as well, if somebody has a better idea...
>
> Andreas

I vote for b. 

No idea for a better name though
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 09.10.07 10:32:39, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > Possible solutions:
> > 
> > a) Always use QString, this is a breakup with
other parts of the
> > platform API which use KUrl
> > b) A new Location type that has operator < or a
qHash function and
> > allows to retrieve either a string or a url and
also knows how it was
> > constructed (i.e. wether it is a repo or local
location)
> > c) Only use QString in VcsDiff and store the
information wether thats
> > repo location or local locations in the VcsDiff
object as well
> > 
> > Personally I'd prefer b) I think, with changing
all QVariant's to
> > Location in the API's but leaving KUrl/QString
API's as they are now.
> 
> b) sounds nice, you could make Location have 'isLocal',
'localPath', 
> 'remotePath' and such if that seems useful.

I already implemented that after Matt said he likes the
version and yes
the class has localUrl(), repositoryLocation() (I thought
path is a bad
thing here as we're not limiting how a repository describe's
its
structure) and also locationType() to return either
LocalLocation or
RepositoryLocation.

There is a small implementation issue right now which I have
to fix
before comitting 

> > Oh and of course the name of the Location type is
subject to discussion
> > as well, if somebody has a better idea...
> 
> "VcsLocation"? Or are we not using
"Vcs" in class names these days? (Or 
> is it namespaced? If it's going to be namespaced,
"Location" seems fine.)

Hehe, yes I meant to write VcsLocation as all other classes
are
Vcs-prefixed. Though I right now wonder wether it would be
better to use
a nested namespace, i.e. 

KDevelop::Vcs::Location instead of KDevelop::VcsLocation

Personally I don't care, unless of course one way is
significant
drawbacks (or the other has significant gains).

Andreas

-- 
It may or may not be worthwhile, but it still has to be
done.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel