VCS Interface classes

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 30.04.07 09:34:40, Jakob Petsovits 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...

(Since Jakob asked for suggestions...) I would actually vote for 
isWorkingCopy also. Maybe it's svn-ish but we're also using svn 
definitions for some things that are used differently elsewhere (e.g. in 
perforce, "merge" is resolve(), and "integrate" is merge()). In some 
cases we just have to pick a standard, and I agree that isWorkingCopy is 
more obvious than isValid. If you want a generic alternative, IMO use 
isVcsControlled. Hmm, you could also overload that to work on files 
also, which might be useful, although it would overlap with status().

>> * 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. 
> 
>> * 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.

Should repositoryVersion() return the very latest global version of the 
repo, or the latest change that affected the file in question? I want to 
say the latter?

Anyway, I guess I am also confused; why is the difference not simply 
whether you gave a repo path vs. a url (i.e. one function)? (But I guess 
this needs the url->repo path function?)

I also realized something unfortunate, but probably unavoidable... it is 
really hard to get the repo version of a directory with perforce. All I 
can figure out to do is get the file version of every file in the 
specified path and compare that to the log() of that path, working 
backwards until you find the revision at which point going further back 
would mean reverting to an earlier version of some file in that path.

>> 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...

...or use the version "WORKING"? This would allow specifying a file by 
local path but diffing a repo version. Alternatively, just ignore the 
parameter in this case (do we really need multiple versions?).

-- 
Matthew
If you believe you received this e-mail in error, you are probably sadly 
mistaken, but if not, aren't you lucky?