[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 10.04.07 10:25:13, Matthew Woehlke wrote:
> 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.

Well, same difference :)

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

Did I say just that? Somehow reads now like 

a) I'm crazy :)
b) context is missing

However I already thought about having a ISCMParameter, the problem here
is: What methods would it have? How can a script create an ISCMParameter
for a given vcs plugin?

> 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.
 
I like this idea, so for svn I'd create just 1 mapping having the
repo-url and the local path. 

So whats difference between an additional class and having a QMap+Flag
(for the recursion thing, or anything the plugin wants to provide as
flags)?

Andreas

-- 
Your lucky color has faded.