[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 09.04.07 16:35:17, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 09.04.07 10:54:11, Matthew Woehlke wrote:
>>>> This brings up a wrinkle... we need to be careful how we define a 
>>>> "checkout scope"... in svn it is just a path; in perforce it is a client 
>>>> view (i.e. a mapping consisting of several path pairs with an optional 
>>>> exclude flag). Tagging needs to take a "checkout scope" as input.
>>> I'm not sure what you mean, but I suppose we can talk about that better
>>> once we have a few interface definitions. I'll try to create at least
>>> the basic one and one for repository stuff tonight.
>> I guess the simple explanation is that the "what part of the repo should 
>> I operate on" argument for checkout() and branch() needs to be some sort 
>> of class that is defined by the VCS plug-in, as opposed to a simple URL. 
>> This is because in perforce you do not check out a URL, you check out a 
>> client spec. Actually this is true for svn too; you don't check out a 
>> URL, you check out a URL /and/ a flag saying if it is recursive or not.
> 
> Actually thats wrong for SVN, you checkout a URL, the flag is just an
> additional parameter.

I disagree, IMO the flag is part of the definition of what you are 
checking out.

> We can't let the plugin tell us which parameters it wants. 

Why not?

> We need to
> find a common parameter format. So what exactly does perforce need for a
> checkout or branch? A list of files (can we use a Url for the elements?)

Short answer:
-------------
Checkouts and branchings need a "view", which consists of a list of 
either inclusive or exclusive mappings from a source URL (a repo path) 
to a destination URL. For clients, the destination URL looks like 
'//client/mapped/path...'. For branch specs it takes a repo URL. Of 
course for a checkout you also need the client root directory, but you 
could munge this from the mapping, i.e. instead of a client path, take a 
file path; the common base for all file paths becomes the client root, 
and is replaced with the client name to generate the client path.

Oh, and this means that for a checkout (and a branch too, actually) you 
must give it a name.

Automation:
-----------
I assume the point of all this is to be able to script a checkout or 
branch without user interaction? I still think I would use a VCS-defined 
object to represent a checkout or branch; it simplifies the interface. 
There should be a factory method to create a placeholder object from an 
identifier (i.e. the name, above). Then there should be a method to add 
a mapping, with an option to make it recursive or not (in perforce, the 
difference is '//URL/path/*' vs. '//URL/path/...', so this would be svn 
compatible) and an option to specify an exclusion. This method is 
allowed to fail if any mapping already exists*, and/or if you request an 
excluding (rather than including) mapping.

(* Except there's no reason we couldn't/shouldn't support multiple 
checkouts in one checkout() for svn, is there? :-))

Of course, there would also be an interactive factory method; possibly 
even an 'edit' method that would let you set something up and then offer 
it to the user to modify before it is used.

Implementation notes:
---------------------
Perforce works on client specs, so a "checkout" would presumably take a 
definition of a client spec, create (or edit) a client, and then set the 
project's VCS options to use that client for future operations (the 
"client" would be somewhat like if you had to tell svn where your 
working copy was for every invocation*). Except for the view it should 
be possible to set all of these automatically, however.

(* It isn't that bad, of course, you typically set an environment 
variable that says what client to use... KDevelop 3.x doesn't do this, 
which is why the current perforce integration is unusable.)

Examples:
---------

A client spec might look like:
====
Client: mwoehlke_kdelibs_35
Owner: mwoehlke
Description:
     This is an example.
Root: /home/kde/src/p4_35
Options: <options aren't important 99.9% of the time>
LineEnd: local
View:
     //branches/KDE/3.5/kdelibs/... \
         //mwoehlke_kdelibs_35/src/...
     //branches/KDE/3.5/kde-common/admin/... \
         //mwoehlke_kdelibs_35/admin/...
     -//branches/KDE/3.5/kdelibs/*PORTING* \
         //mwoehlke_kdelibs_35/src/*PORTING*
====

...and a branch spec might look like this:
====
Branch: kde_357
Owner: apakulat
Options: <options aren't important 99.9% of the time>
Description:
     KDE 3.5.7 tag.
View:
     //branches/KDE/3.5/... //tags/KDE/3.5.7/...
====

-- 
Matthew
GDRLaH - Grin, Duck, and Run Like a Hippo! :-)