[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 12.04.07 17:20:28, Matthew Woehlke wrote:
> 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? :-)

Its not, I was just stating that you convinced me this even makes sense
for svn. All I was saying is that I don't think we should have something
like
QMap<QStringList,Qstring>
i.e. multiple sources are mapped to the same target, at least not this
way, but by having multiple entries in the map with the same value.

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

Typo by me, its supposed to be 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.

Huh? The class I presented was meant only as a convenient container for
the information. If the Ui wants to populate an instance it just uses
the addMapping() (I left out uninteresting things like removeKey() and
stuff like that).

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

I don't think so.

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

Uhm, IMHO that class is just a container for the information, i.e. it
has the mapping information in the instance and thats what all plugins
will just use and interpret the way they need it.

I don't think it makes sense to let every plugin define its own
implementation of such a basic container class.

Andreas

-- 
Executive ability is prominent in your make-up.