[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 13.04.07 11:06:44, Matthew Woehlke wrote:
>> 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/*).
> 
> Hmm, why does that not work? I thought thats how perforce works, i.e.
> you explicitly state which things you want in your client.

Probably because the reverse mapping is ambiguous, i.e. if try to 
add(/path/to/foo/object.c), is that //foo/bar/object.c or 
//cow/pig/object.c? :-) Anyway what actually happens is the first 
mapping is just ignored.

This I assume would work:

//foo/bar/a* -> /path/to/foo/a*
//cow/pig/b* -> /path/to/foo/b*

(The perforce back-end will need to be careful how it manages svn-style 
paths; probably the above example will only work with the perforce 
back-end. It might be necessary to add a flag that says 'this is a 
perforce-style mapping' to avoid translation, but that's all back-end 
implementation detail that is not important for our present purposes.)

>> //foo/bar
>> //foo/cow -> /path/to/somewhere
>> //foo/pig
> 
> Yes do need this one. This is perfectly fine for checkout or branch in
> svn. Except that with the current API we'd have 
> 
> //foo/bar -> /path/to
> //foo/cow -> /path/to
> //foo/pig -> /path/to
> 
> You'll end up with /path/to/foo, /path/to/cow and /path/to/pig.

No, that's not right, you're omitting the destination argument. IMO the 
destination should be required, i.e. what you just described would be:

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

Otherwise you lose the functionality of giving a destination... and it 
is incompatible with how perforce treats mappings.

> Maybe I'm missing something, but I don't see how a virtual addMapping
> would provide any error-checking. And the checking for validity should
> be done in checkout and branch respectively as they know how to treat a
> given list of mappings.
> 
> Aaah, now I got it, you want to do the error checking in addMapping, no
> I don't think that works. How should addMapping know in which function
> it is used later on.

You don't/can't. That's why I agreed last post that you're right. :-)

-- 
Matthew
Current geek index: 62%