[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 13.04.07 14:13:22, Matthew Woehlke wrote:
> 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.

Aaah, so this is different from SVN where I'd get /path/to/foo/bar and
/path/to/foo/pig. perforce literally puts everything into the
destination? Then I guess we shouldn't omit the exact destination.

> >> //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:

See above, agreed.

Andreas 

-- 
Your boss climbed the corporate ladder, wrong by wrong.