[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 12.04.07 15:58:00, Matthew Woehlke wrote:
> 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.

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.

> > 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.

> > 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.

> 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? 

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).

Andreas

-- 
You feel a whole lot more like you do now than you did when you used to.