[VCS] Merging IAtomic* into IBasic*

[Andreas Pakulat]

On 10.05.07 15:29:54, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 10.05.07 13:00:13, Matthew Woehlke wrote:
> >> Andreas Pakulat wrote:
> >>> On 10.05.07 10:10:22, Matthew Woehlke wrote:
> >>>> Just to clarify:
> >>>> repositoryRevision gets the most recent revision committed to the /whole 
> >>>> repository/ (like the "Last Changed Rev" in 'svn info'). So if I am 
> >>>> understanding you correctly, there is no such thing in CVS. Note that 
> >>>> repositoryRevision does *not* take a repo path. I think you would use 
> >>>> log() to get the information you are talking about.
> >>> Did you look at repositoryRevision lately? It does take a path and IMHO
> >>> its not what you want it to be. It tells you the last revision when the
> >>> given path was changed. What would use-case do you have for knowing the
> >>> latest global revision number?
> >> Hmm, so it does, in which case I am mis-remembering. Given that it is in 
> >> IAtomicBrowsableVC I think I must have meant for it to work as described 
> >> above, since as it is currently written, it does indeed belong in 
> >> IBrowsableVC. That being the case, do you think it's worth keeping 
> >> repositoryRevision when it's just a simplified log()?
> > 
> > Its not a simplified log. repositoryRevision returns just the exact
> > revision for HEAD (it shouldn't be just head but the number). log()
> > returns what has changed for a given revision.
> 
> It isn't? Does log(repoPath, VcsRevision::Head, 1) not provide the same 
> information?

Well, its not just simplified IMHO. Its purpose is different, log lets
you find out what change was done to a file in the last n revisions
starting with the given one. While repositoryRevision is really just to
find out the exact number of the latest change. Yes you can achieve that
through log too, but log means something different to users - IMHO.

> >> I guess the only obvious use case is to facilitate getting a list of 
> >> changes by means other than calling log() on the repository root.
> > 
> > My use case is simply letting a script determine wether the local copy
> > of a file is up-to-date or not. So it would do something like:
> 
> Right, but log() should be able to do that. The time difference between 
> using log() and 'svn info'/'p4 fstat' seems to be noise, so I don't see 
> a performance reason for a separate method. That said, I guess we can 
> provide it for symmetry with localRevision, which is less redundant 
> because localRevision might not need a connection to the remote VCS 
> where log(localPath) might. In any case, we agree that it should move to 
> IBrowsableVC, right?

Hmm, that leaves us with just 1 method in an interface. That looks just
wrong. I can think of only 1 solution: Move change() either to the Basic
or Browsable interface and define that either the return value of
change() may be invalid (for CVS for example) or that functions like ls
don't have to work allways.

> > if( rev1 < rev2 ) then do something fancy, like rm -rf /home
> 
> Um... no? ;-) I think doing update() would be a better idea :-).

Well, replace it with some small highlighted item to tell the user: hey
something happened to that file which you are monitoring. I think this
can be useful with the basket-idea from David, kdevelop could monitor
automatically the few files in the basket and let the user know when
something changed...

> Any thoughts on what this function should look like? I'm not fond of 
> operators because a comparison might mean consulting the repo (think of 
> comparing a Date to a GlobalNumber) and might fail (comparing a 
> FileNumber to anything else, or a Range to anything). I guess comparing 
> two FileNumbers should assume that they represent the same file; the 
> conversion would be painful otherwise.
 
Hmm, right. We could define that only two revision of the same type can
be compared. As all our methods take a revision type that the user can
request this should be enough.

About FileNumber: Those are actually meaningless without an associated
path - IMHO - so maybe the revision should carry this information (the
repo path) internally. Not sure if this should be made accessible, but
it might make sense..

> >> This brings up two other questions... Should we have a repositoryRoot() 
> >> function?
> > 
> > What for?
> 
> log(repositoryRoot(), VcsRevision::Head, limit) to get a list of all 
> changes that have happened anywhere.

Hmm, I still can't see how this is useful information, especially in CVS
(In svn it might be interesting, not sure about the usefulness though)

Also the above doesn't work that way, there's no Repository class
anywhere so repositoryRoot() would at least need a repoPath to start
with.

> Also it's pretty important for a remote repository browser to know :-)
> (although I suppose it could require you to specify this).

Uhm, the vcs plugins don't have any state so they can't know the
repositoryRoot() without supplying them some information for what
file/repopath you want to know the root.

> > How do you determine that?
> 
> In perforce the root is simply '//' by definition. In svn, 'svn info' 
> knows what the root is.

Well yes. But that is getting even more unusable. If I work on project
foo in a large repo with 100 projects, then I will probably never do a
log(repoRoot()) because that would give me too much noise. Or rather in
that case I'd like to have repoRoot == my projects top-dir in the repo.

> > For CVS the root is pretty clear but
> > doesn't give you anything useful, because you work on modules there.
> 
> Again, I don't know CVS. Is the case above (log(theRoot)) possible? 
> (Robert-or-someone-else-that-knows-CVS?)

I think thats what cvs history is about, but that output is not
parseable for a normal human without a handbook of cvs history (which I
don't have at hand).

Andreas

-- 
You'll never be the man your mother was!