[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

(I wish gmane would keep up. Sigh. I see your reply, but not my message.)

Andreas Pakulat wrote:
> On 09.04.07 14:34:06, Matthew Woehlke wrote:
>> integrate = Tell the VCS what you are doing (in some VCS's this also 
>> adds metadata about the integration so you can see that such-and-such 
>> version is the previous version plus integrations from somewhere else, 
>> possibly with edits on top of that also). If we have branch, we need 
>> integrate.
>>
>> merge = Resolve conflicts, either from an update of something you were 
>> editing, or from an integration (i.e. merge != integrate; merge is a 
>> 100% client-side operation). If we have update and diff (of course we 
>> do), we need merge.
>>
>> Some VCS's may do the "merge" step implicitly during an integrate or update.
> 
> In SVN terms your merge is a manual operation which needs to be done
> when there are conflicts. It is finalized be either svn resolved or svn
> revert. Changes that don't create a conflict (i.e. lines that have not
> been modified locally) are automatically integrated upon doing svn up.

I'm getting this from the 'p4merge' tool which is a sort of glorified 
diff3 that allows editing. The objective here is that this is like 
'diff', but you take a file that needs to be resolved and present the 
working copy, the "base", and the "copy being integrated", and then you 
pick and choose what changes you want and from where.

In the case of an update conflict, the "base" is the revision you were 
editing minus changes, and the "copy being integrated" is the version 
you tried to update to. In the case of an integrate, the "base" is the 
"from" revision and the "copy being integrated" is the "to" revision.

Maybe it would be better to call this "resolve" and call "integrate" 
"merge". I was using "merge" because 'svn resolved' does not do this, it 
would be the equivalent to the 'use working copy' action of this.

> As for integrate: There's no exact match in svn, svn merge comes close,
> but thats merging 2 versions of a url into the working copy. You can use
> the diff between two "branches" of svn (i.e. 2 different urls, like
> branches/3.5 and trunk) or you can use 2 revisions of the file in the
> same repository url (i.e. merge changes between 121423 and 342232 into
> WC) or use differences between 2 other working copies.

Isn't that what I said? If I understand correctly, 'svn merge' generates 
a diff between S1 and S2 (whatever those are) and then applies that diff 
to "a url into the working copy". This seems to be *exactly* what 
perforce does... except that perforce does not do the merge step 
implicitly as svn apparently does. So whereas svn /might/ leave /some/ 
files in a conflict state (or does it force you to resolve on the 
spot?), perforce /always/ leaves /all/ files in a conflict state.

The good news is that client specs aren't used here, so the prototype 
would be (omitting 'const' and '&'):

integrate(KVcsUrl src, KVcsUrl dest, KVcsGlobalRevision from_ver,
           KVcsGlobalRevision to_ver = KVcsGlobalRevision::latest);

The question here might be if doing an integrate() with perforce has to 
force an interactive merge(), so that the VCS interface functions 
consistently?

>>> IMHO the integration would go to basic interface among the
>>> separate interfaces.
>> It should go wherever 'branch' is IMO, since if you can't branch, you 
>> have nothing to integrate.
> 
> I agree. With svn I think the most used actions are integrating the diff
> between 2 revisions of a repository url or between 2 repository urls. So
> it fits perfectly into the planned (by me of course)
> ISourceCodeRepository. However I probably call it merge as that fits
> better with what it does, IMHO.

Ok, so... we rename what I called "merge" to "resolve", and "integrate" 
to "merge"? That's fine with me.

-- 
Matthew
If you believe you received this e-mail in error, you are probably sadly 
mistaken, but if not, aren't you lucky?