[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 11.04.07 10:15:48, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> I like this idea, so for svn I'd create just 1 mapping having the
>>> repo-url and the local path. 
>> Right... except, why just one? :-) Certainly I would assume branching 
>> can handle many (you might have to do them one at a time, but that's a 
>> back-end detail),
> 
> Well, I don't think people branch multiple things at once, i.e.
> http://foobar/app1->http://foobar/branches/app1-todo
> http://foobar/app2->http://foobar/branches/app2-todo
> doesn't seem like a normal thing to do. But hey whatever, if the API
> supports...

Well, I'm biased by... um, history (I didn't lay out our repo). I have 
never branched *fewer* than about a half dozen or so things at once. 
Anyway if the repo supports a list of maps (and IMO it should) this is 
no big deal, you just do each branch one at a time and commit once.

I guess this doesn't happen in KDE, but a use-case would be if you 
wanted to branch kdelibs, kdebase, and kdesdk but nothing else, then you 
would need a list. A checkout is certainly similar, you almost certainly 
want kdelibs, kdepimlibs, and kdebase and probably some others, but 
probably not all of KDE/.

>> and you can check out several things, again one at a 
>> time. Doesn't svn even figure out how to correctly do an update when you 
>> do this? (e.g. the admin directory we have in 3.x?) Or am I imagining that?
> 
> Pulling stuff from other URL's is done differently in svn, it uses
> svn:externals for that. A working copy is always checked out from 1
> directory (+any externals, but those are properties of one of the
> subdirectories in the checked-out-dir).

Hmm, ok, but (see above) you still might want to check out a bunch of 
dirs into one (non-versions) root. So maybe the svn back-end would not 
support lists the same way as perforce, i.e. no nested check-ins. That's 
not a problem because there are also some funny rules in perforce about 
nested mappings, we just say up front that some mappings are not 
permitted and that the back-end will define these.

>>> 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)?
>> You mean that each item in the QMap has a flag, yes? :-) Hmm... maybe 
>> that works, although I don't see why you wouldn't just use a list. 
> 
> I actually meant 1 flag for all entries, but I think per mapping is
> better.

It is also /required/ to be per-map for perforce, to support exclusion 
mappings. :-)

> And then QMap doesn't work anymore... 

...the "value" can't be an arbitrary class? Although I think the current 
idea is probably best.

> So I guess something like
> this is ok (possibly some more convenience stuff):
> 
> ISCMParameter{
> public:
>   enum CheckoutFlag{
>     Recursive,
>     NonRecursive
>     };
>   void addMapping(const QString& key, const QString& value, CheckoutFlag);
>   QStringList keys();
>   QStringList value(const QString& key);
>   CheckoutFlag flag(const QString& key);
> };

Shouldn't CheckoutFlag be a list also? Otherwise that looks fine, pretty 
much what I was thinking. I would add also a virtual method to set the 
map via UI also so back-ends can subclass this and expose all features 
supported by the VCS, while still providing an interface that scripts 
can use. Or an interface method to get a ISCMParameter instance via UI; 
same difference.

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