VCS Interface classes

Hi,

I present to you our new VCS interface classes (that I
finally managed
to write up, based on the enourmus thread some time ago).

I'd like to keep the discussion to a minimum, so here are
the points
that are allowed to be discussed ;)

* major problems for a given system with the proposed
interface
* return types for the methods, we need a way to communicate
at least
  errors back, but I'm not sure how to do that best given
that the 
  methods should execute asynchronously
* Parameters for push/pull in the distributed vcs iface, no
idea whats
  needed there
* diff and log parameters, am not 100% sure there
* usage of simple QString's for any parameter that can be a
repository
  url (anything that is always a local url should stay
KUrl), if a VCS
  system can't use a url for describing a repository
location

I've tried to give some reasonable information about the
various
methods.

I think a week for discussion is enough (unless somebody
plans vacations
during the next week), thus I'm going to commit these
interfaces to svn
next weekend or on the bic monday. I'm not yet sure wether I
remove the
existing iface class (and force our two vcs-plugin-coders to
move to the
new interface) or wether I'll leave them in for another two
or three
weeks. Input on that is appreciated too.

Andreas

-- 
Everything will be just tickety-boo today.

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

On 30.04.07 02:22:02, Andreas Pakulat wrote:
> Hi,
> 
> I present to you our new VCS interface classes (that I
finally managed
> to write up, based on the enourmus thread some time
ago).
> 
> I'd like to keep the discussion to a minimum, so here
are the points
> that are allowed to be discussed ;)
> 
> * major problems for a given system with the proposed
interface
> * return types for the methods, we need a way to
communicate at least
>   errors back, but I'm not sure how to do that best
given that the 
>   methods should execute asynchronously
> * Parameters for push/pull in the distributed vcs
iface, no idea whats
>   needed there
> * diff and log parameters, am not 100% sure there
> * usage of simple QString's for any parameter that can
be a repository
>   url (anything that is always a local url should stay
KUrl), if a VCS
>   system can't use a url for describing a repository
location
> 
> I've tried to give some reasonable information about
the various
> methods.
> 
> I think a week for discussion is enough (unless
somebody plans vacations
> during the next week), thus I'm going to commit these
interfaces to svn
> next weekend or on the bic monday. I'm not yet sure
wether I remove the
> existing iface class (and force our two
vcs-plugin-coders to move to the
> new interface) or wether I'll leave them in for another
two or three
> weeks. Input on that is appreciated too.

And as always I forget to attach the files :P

Andreas

-- 
Your temporary financial embarrassment will be relieved in a
surprising manner.

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

2007/4/29, Andreas Pakulat <apakugmx.de>:
> Hi,
>
> * diff and log parameters, am not 100% sure there

virtual void log( const KUrl& localOrRepoLocation,
              const QString& revision ) = 0;

1.
How can the caller know repository location for the given
local file?
i.e. suppose there is /home/kdev/kdevelop/main.cpp.
The caller doesn't know whether it is

svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop/.... or
https://s
vn.kde.org/home/kde/trunk/KDE/blah

2.
Subversion accepts start revision and end revision.

Solution is Just specify the local URL only and,
Detailed options will be specified by each VCS plugin
itself.
For example, some plugin will invoke option dialog box and
have the
user specify it.
The option dialogbox is necessary anyway because
in case of svn, there are 3 optional useful parameters for
logview.

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

2007/4/29, Andreas Pakulat <apakugmx.de>:
> Hi,
>
> * diff and log parameters, am not 100% sure there

virtual void log( const KUrl& localOrRepoLocation,
              const QString& revision ) = 0;

1.
How can the caller know repository location for the given
local file?
i.e. suppose there is /home/kdev/kdevelop/main.cpp.
The caller doesn't know whether it is

svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop/.... or
https://s
vn.kde.org/home/kde/trunk/KDE/blah

2.
Subversion accepts start revision and end revision.

Solution is Just specify the local URL only and,
Detailed options will be specified by each VCS plugin
itself.
For example, some plugin will invoke option dialog box and
have the
user specify it.
The option dialogbox is necessary anyway because
in case of svn, there are 3 optional useful parameters for
logview.

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

On 30.04.07 02:36:38, dukju ahn wrote:
> 2007/4/29, Andreas Pakulat <apakugmx.de>:
> > Hi,
> >
> > * diff and log parameters, am not 100% sure there
> 
> virtual void log( const KUrl& localOrRepoLocation,
>               const QString& revision ) = 0;
> 
> 1.
> How can the caller know repository location for the
given local file?

no, thats not when a repoLocation is used. If a repo
location is used a
history of that repo location should be displayed. 

> 2.
> Subversion accepts start revision and end revision.

Yeah and it accepts a log-limit and other arguments. This
needs to be
done by the plugin. The log method only tells the plugin to
show the
history of a location. The revision argument is meant to be
used for
repo locations, I guess we really should do 2 methods one
for local and
one for repo locations.

Andreas

-- 
Be careful!  Is it classified?

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

On Monday, 30. April 2007, Andreas Pakulat wrote:
> > * I think isValidDirectory() should be named
isWorkingCopy(), because on
> > reading this name you instantly know what is asked
for.
> > ("what does valid mean here?")
>
> Well, WorkingCopy seemed to be too svn-ish...

Well ok, whatever, it's just a cosmetic change anyways.
I thought the term to be used more widely, but I'm kinda
SVN-biased as well.
Matthew, Kuba, your take?

> > * edit() is also not quite what the method is
doing, how about
> > setEditable()?
>
> IMHO setEditable is not really proper, for me it always
means setting a
> flag, which is not the case here. This may mean to
fetch a file from the
> repository to make it editable.

Sounds reasonable, let's stay with edit().

> > * repositoryRevision() vs. localRevision() - what
is the difference here?
>
> Simple: repositoryRevision() will give you the revision
of that file on
> the repository, local will give you the local revision
(i.e. svn info
> foobar, for example). This is the same after update()
or commit() but
> might be different in other times.

Obviously doesn't apply to SVN and CVS (everything except
the checksum stays 
the same), but if you say it's necessary for other VCSs,
I'll believe you 

> > Also, any particular reason why the parameter is
restricted to local
> > copies?
>
> Well, repositoryRevision should really just check the
revision of a
> local file in the repository, so I don't see the need
to have a
> repository location here.

Ah right, makes sense.

> > * The above essentially also applies to diff(),
but I'm not sure if it's
> > a good thing to make the parameters more
complicated for such an edge
> > case.
>
> A list will be possible for most of the operations,
i.e.
> add,remove,diff,update,log.

Oh cool, I totally forgot about those. Then again,
everything but commit is 
less tragic because one composite action can easily be
emulated by multiple 
atomic ones.

> > Question: what dstRevision will the method receive
if the LocationDst is
> > a locally modified file inside the working copy?
That's important to
> > document, as it's the primary use case.
>
> I don't think dstRevision should be used in that case,
dstRevision is
> meant to be used when specifying a repository location.
Maybe we
> shouldn't do this in 1 method but split those that can
take either repo
> location or local one...

+1 for object oriented languages' method overloading feature

Like, an extra method for that standard use case:
virtual void diff( const KUrl& localLocation ) = 0;
(or the "list" version of that.)
I'm all for a split.

Had a short look at the other files, and they look fine -
except for the 
distributed interface, I haven't got enough knowledge of how
that works.

Cheers,
  Jakob

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

On 30.04.07 14:29:50, Jakob Petsovits wrote:
> On Monday, 30. April 2007, Andreas Pakulat wrote:
> > > * repositoryRevision() vs. localRevision() -
what is the difference here?
> >
> > Simple: repositoryRevision() will give you the
revision of that file on
> > the repository, local will give you the local
revision (i.e. svn info
> > foobar, for example). This is the same after
update() or commit() but
> > might be different in other times.
> 
> Obviously doesn't apply to SVN and CVS (everything
except the checksum stays 
> the same), but if you say it's necessary for other
VCSs, I'll believe you 

No, the repositoryRevision can differ from the localRevision
if somebody
else does something to the same file (without the local file
being
updated). I think this is more or less just convenience for
scripts
which can this way easily find out wether the file is
up-to-date or not
(without having to execute a full status on the parent
dir).

> > > * The above essentially also applies to
diff(), but I'm not sure if it's
> > > a good thing to make the parameters more
complicated for such an edge
> > > case.
> >
> > A list will be possible for most of the
operations, i.e.
> > add,remove,diff,update,log.
> 
> Oh cool, I totally forgot about those. Then again,
everything but commit is 
> less tragic because one composite action can easily be
emulated by multiple 
> atomic ones.

Yeap, I already changed the interfaces here, basically
everywhere where
only a localLocation was used now its a list of
locations...

> > > Question: what dstRevision will the method
receive if the LocationDst is
> > > a locally modified file inside the working
copy? That's important to
> > > document, as it's the primary use case.
> >
> > I don't think dstRevision should be used in that
case, dstRevision is
> > meant to be used when specifying a repository
location. Maybe we
> > shouldn't do this in 1 method but split those that
can take either repo
> > location or local one...
> 
> +1 for object oriented languages' method overloading
feature 
> Like, an extra method for that standard use case:
> virtual void diff( const KUrl& localLocation ) =
0;
> (or the "list" version of that.)
> I'm all for a split.

Yeap  and with the confusion that dukju showed I'll do that
later today.

> Had a short look at the other files, and they look fine
- except for the 
> distributed interface, I haven't got enough knowledge
of how that works.

Yeah, me neither. I once used svk shortly but I really have
no idea
wether push/pull is all thats needed and which parameters
are needed
there.

Andreas

-- 
Beware of a tall blond man with one black shoe.

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

On Monday, 30. April 2007, Andreas Pakulat wrote:
> On 30.04.07 14:29:50, Jakob Petsovits wrote:
> > On Monday, 30. April 2007, Andreas Pakulat wrote:
> > > > * repositoryRevision() vs.
localRevision() - what is the difference
> > > > here?
> > >
> > > Simple: repositoryRevision() will give you
the revision of that file on
> > > the repository, local will give you the local
revision (i.e. svn info
> > > foobar, for example). This is the same after
update() or commit() but
> > > might be different in other times.
> >
> > Obviously doesn't apply to SVN and CVS (everything
except the checksum
> > stays the same), but if you say it's necessary for
other VCSs, I'll
> > believe you 
>
> No, the repositoryRevision can differ from the
localRevision if somebody
> else does something to the same file (without the local
file being
> updated). I think this is more or less just convenience
for scripts
> which can this way easily find out wether the file is
up-to-date or not
> (without having to execute a full status on the parent
dir).

Ah! Now I get it.
Sure as hell, this stuff has to be documented very nicely.

> > Had a short look at the other files, and they look
fine - except for the
> > distributed interface, I haven't got enough
knowledge of how that works.
>
> Yeah, me neither. I once used svk shortly but I really
have no idea
> wether push/pull is all thats needed and which
parameters are needed
> there.

I'll do an analysis of how git works in June, but no idea if
it still matters 
at that time :-P

Jakob!

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

On Monday, 30. April 2007, Jakob Petsovits wrote:
> On Monday, 30. April 2007, Andreas Pakulat wrote:
> * I think isValidDirectory() should be named
isWorkingCopy(), because on
> reading this name you instantly know what is asked
for.
> ("what does valid mean here?")

On further thought, I really think this should apply to both
directories AND 
files. After all, it may be a good thing to tell apart all
the source files 
that have been left out of the repository from the
"real files".

That would (perhaps not important at all, but anyways) also
provide a way to 
emulate an "export" action. Speaking of which, has
this one been left out of 
the interfaces conciously?

As a nice side effect, that makes a real good case for
isWorkingCopy() 

Wishes,
  Jakob

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

On 30.04.07 16:32:55, Jakob Petsovits wrote:
> On Monday, 30. April 2007, Jakob Petsovits wrote:
> > On Monday, 30. April 2007, Andreas Pakulat wrote:
> > * I think isValidDirectory() should be named
isWorkingCopy(), because on
> > reading this name you instantly know what is asked
for.
> > ("what does valid mean here?")
> 
> On further thought, I really think this should apply to
both directories AND 
> files. After all, it may be a good thing to tell apart
all the source files 
> that have been left out of the repository from the
"real files".
> 
> That would (perhaps not important at all, but anyways)
also provide a way to 
> emulate an "export" action. Speaking of
which, has this one been left out of 
> the interfaces conciously?

No, it was just forgotten  And I'm
not sure every VCS supports this,
but I guess it can be emulated...

> As a nice side effect, that makes a real good case for
isWorkingCopy() 

Uhm, no. Then the function should rather be
isVersionControlled() or
isUnderVersionControl(). 

Also the export function in svn allows local or repository
URL's, but I
think we should limit this to local urls for now.

Actually at some point I wanted to split local and remote
methods, so
remove methods would be in a separate interface....

Andreas

-- 
You are number 6!  Who is number one?

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