[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> 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:
>> 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. 

Ah. In that case, please excuse my confusion. :-)

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

No, not like that we don't need it. I don't think we should prevent the 
user (not in the interface, anyway) from trying to create a map like:
//foo/bar -N -> /path/to/foo
//cow/pig -N -> /path/to/foo

...because that's legal in perforce... it doesn't *work* :-) but it is 
legal. (NOTE: -N meant non-recusrive, i.e. in perforce this is actually 
e.g. //foo/bar/*).

At any rate, this is certainly permissible (I'm actually using something 
like this):
//foo/bar -> /path/to/foo
//foo/dog -> /path/to/foo/dog

But if I am understanding you, we certainly don't need:

//foo/bar
//foo/cow -> /path/to/somewhere
//foo/pig

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

Ok, I follow you now. Yes, that's fine (now that I'm reading it right! :-)).

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

I was thinking it would be great if the interface could provide a UI to 
create this rather than /needing/ to write one per back-end. That should 
be do-able if you have a way to ask the back-end for a list of valid 
flags, yes? And the back-end can provide it's own UI if it wants to.

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

Hmm, ok so then you have to check when you want to use a ISCMParameter 
if it is valid? Seems like more code (well, not really, you would write 
an isValid() to call as needed) but then I guess you can reuse 
ISCMParameter for checkout and branch, which have different semantics. 
That works.

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

Well they wouldn't implement the storage, just override some methods to 
provide error checking... but see above; you convinced me. :-)

-- 
Matthew
Current geek index: 62%