[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 13.04.07 11:06:44, Matthew Woehlke wrote:
> 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:
> > 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/*).

Hmm, why does that not work? I thought thats how perforce works, i.e.
you explicitly state which things you want in your client.

> 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

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.

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

You're confusing supplement library and interface. Our interface are
pure abstract classes with no implementation. They just define the
methods that the plugin implementing the interface needs to provide.

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

Uhm, we surely can have some UI for setting up a parameter instance and
its not much of a problem to provide more entries in the flags combobox
if the plugin wants to add something.

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

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.

Andreas

-- 
You are confused; but this is your normal state.