[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 12.04.07 15:58:00, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> 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.
> 
> That actually does happen in KDE4 development, at least if you do a
> larger change in kdelibs which doesn't affect all modules (no specific
> idea, stuff like kconfig changes need all modules in KDE/). So yes, this
> is something we should have, still I think a list of mappings is ok
> here, even if the right side of the mapping is the same for all entries.

Ok, I'm confused. How is that different from what I was suggesting? :-)

>>> And then QMap doesn't work anymore... 
>> ...the "value" can't be an arbitrary class? Although I think the current 
>> idea is probably best.
> 
> I wanted to use QMap for the mapping of urls/paths, so we could do
> something like 
> 
> QMap<QString,QPair<QString,flag>> but this is not something to easily
> work with.

That's fine, I mainly care that it does what it needs to, not how it 
does it. :-)

>>> 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?
> 
> Huh? I don't see a list here at all. CheckoutFlag is now a
> per-mapping-setting.

D'oh, I am seeing members, not functions. But then why is value(key) a 
QStringList and not a QString?

>> 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.
> 
> I've got a small headache and need to get to bed, so I'm not really
> following you here. A virtual for doing what? 

Sorry, hope you feel better! I was thinking we should have a way to 
populate one of these with a back-end defined UI (this way the UI could 
present paths in the VCS format that the user may be more familiar 
with), but maybe that's not such a good idea and we just need a way to 
get what the legal flags are.

Oh, and for error-checking, addMapping() should probably be virtual 
(well, it pretty much has to be, yes?).

> Also I guess this wouldn't be an interface, but an implementation.
> Because it will basically be a wrapper on top of
> QMap<QString,QPair<QString,CheckoutFlag>> (or similar).

Semantics. :-) The "interface" is the base class that defines the API, 
the back-ends would indeed provide "implementations".

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