VCS Interface classes

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 02.05.07 18:19:49, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 02.05.07 15:45:02, Matthew Woehlke wrote:
>>> Ugly as hell - IMHO. Let the plugins implement diff the way they want
>>> it, you simply can't get everything under one hood.
>> See above. But, just to be clear, I'm talking about /showDiff()/, not 
>> diff().
> 
> See further above. I thought you were talking about normal diff(). If
> this is about code-reuse for showDiff so the plugins don't invent their
> own machinery for showing a unified diff then we're totally on the same
> page with this (not the cat-move though).

I snipped above, but in short, yes. I can live with cat() staying put, 
it just feels odd that you can effectively do it through diff() in 
IBasic. :-)

>>>> The opposite of 'svn log --stop-on-copy' :-). (Sorry, perforce 
>>>> terminology slipping in again.) In perforce you have to specifically 
>>>> request this, although I think (like svn) it should be default. I was 
>>>> just wondering if you think there should be an option to disable this?
>>> In a GUI maybe, not via scripts, too much a border case - IMHO.
>> Maybe. I'm not arguing for it either way, I'd be fine making 'follow' 
>> the default and non-optional. Although I do wonder if log() should 
>> return the repo path at each revision, otherwise can you ask about an 
>> old version with a different name? (I know svn doesn't give file name by 
>> default, and frankly, it drives me nuts, because you don't know what's 
>> happening. IMO log() should tell you what repo path each entry is 
>> talking about. :-))
> 
> Well, we can change the return value of log easily to this:
> [snip example]

Yes, but it would be best to have only the file you asked about, 
otherwise you still can't determine the source of a copy. :-(

In fact, I /still/ can't figure out how to make svn tell you that. The 
repo clearly *has* this information, but... (Maybe the libs are better?)

As a counterexample, here is what perforce would tell you:

//branches/KDE/3.5/kdelibs/kate/part/katehighlight.cpp
... #5 change 60123 edit on 2007/05/02 by mwoehlke at kde35 (text) 'msg'
... #4 change 60091 integrate on [...]
... ... edit from //trunk/KDE/kdelibs/kate/part/katehighlight.cpp#37
... #3 [...]
... #2 change 66234 integrate on [snip]
... ... merge from //trunk/KDE/kdelibs/kate/part/katehighlight.cpp#37
... #1 change 54876 branch on [...]
... ... branch from //trunk/KDE/kdelibs/kate/part/katehighlight.cpp#22
//trunk/KDE/kdelibs/kate/part/katehighlight.cpp
... #22 change 54321 edit on [...]
[...]

Obviously that needs serious parsing into something standardized, but 
notice how detailed it is? The second entry tells me that I integrated 
changes from #37 in //trunk, and that I edited the file before 
committing (compare to #2 where only integration was done). #1 tells me 
that I copied from //trunk to create the file (and that no edits 
occurred in the process).

At the very least, I would like to be able to get from svn the source of 
a copy operation.

So, perforce tells you:
{
   <repo location>
   {
     "..." <file rev#> <global rev#> <action> <date>
      <user>"@"<workspace> <type> <message>
      ["... ..." <copy-action> <copy-source>]
   }+
}+

<type>, <workspace>, and <file rev#> would be perforce extensions, but I 
would prefer to get the rest of that information out of all VCS's 
(<global rev#> becomes the generic <revision>, which of course /is/ a 
file revision number in e.g. CVS). <action> and <copy-action> would be 
combined; if a VCS only knows about the 'edit' action, that's fine (but 
I imagine 'add' and 'delete' are also universal). <repo location> would 
be folded into each entry so we don't have a tree.

>>>>>> Ok, addition: IFooVersionControl (AtomicBrowsing?):
>>>>>> revision(Revision) // gets information about a specified revision.
>>>>> Thats rather logMessage(Revision) IMHO
>>>> ...logMessage() sounds to me like a subset, not a superset, of log() 
>>>> (referring to what information you get back) :-). Not that I'm really 
>>>> crazy about revision() either, to be honest.
>>> Maybe I misunderstood but IIRC you wanted to get the same information as
>>> log has just for a specific revision right?
>> Yes and no. You get the user, date, etc. You /also/ get a list of what 
>> files the change affected, and preferably in what manner (i.e. 
>> add/del/edit). The whole point is to find out 'what did XX revision 
>> change?'.
> 
> see above, we can certainly do something like
> 
> log( path, revision, fullinfo/shortinfo)

The reason I split them is I would prefer log() to only tell you about 
the file you asked about. Hmm... come to think of it, revision() would 
return a slightly different data set:

<revision> <date> <user> |<workspace>| <message>
{
   <repo path> |<file rev#>| <action> [<copy-source>]
}+

(stuff in |'s would be perforce extensions. Stuff in []'s is optional, 
i.e. only if supported and if it applies to the particular entry.)


>>>> (Also, does this mean there is no way to ask about
>>>> /just/ a directory? Is that desirable?)
>>> Not sure what you mean but I do get status information on just a
>>> directory inside a working copy:
>> I meant how would you do this with the interface. Behave differently 
>> based on the presence/absence of a trailing '/'? I guess that would 
>> works. :-)
> 
> I'd like to avoid such things, i.e. different behaviour wether a
> trailing slash exists or not. How about this: 
> 
> status( dir, nonrecursive ) returns a map of all files/dirs in that dir
> with their status + 1 status for the dir itself
> 
> status( file, nonrecursive ) returns a map with 1 entry with just the
> status of the file.
> 
> Thats what I'd expect, so if I give it the working copy its easy for
> svn, if I give svn a dir inside the working copy svn has to do some more
> svn status calls then (or reduce the return value of a recursive call).
> Not a big deal.

I can live with that. I'm biased by perforce, which can't do that (i.e. 
status(dir, nonrecursive) will require listing the directory in order to 
generate arguments).

-- 
Matthew
Disadvantage: Bad Puns [-5]
You constantly utter puns so egregious as to cause mental distress to 
anyone hearing them. This can, however, be used to distract enemies.