[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 09.04.07 17:42:46, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>> I was using "merge" because 'svn resolved' does not do this, it 
>> would be the equivalent to the 'use working copy' action of this.
> 
> Yeap, I think we can use KDiff3 for our GUI for those merge-stuff. Or
> write our own version of it, because we need stuff like "working copy",
> "repository" and "target" instead of temporary file names.

Er... we should modify kdiff3 to allow specifying a "display name" of a 
file (as opposed to the actual file name, when using temp files). AFAICT 
this is how p4merge works.

> svn only has conflicts where the same files were edited in the working
> copy and the diff. There are no other types of conflicts that need to be
> solved. So yes, svn does the merging automatically.

Ok, a perforce back-end may need to force a resolve to happen as part of 
a merge(), in that case, but that's an implementation detail. (Because 
perforce does not automatically resolve, you can selectively apply a 
merge...)

What happens in svn when a merge fails?

>> 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?
> 
> I think that makes sense, yes. Or are there cases where you do the
> integrate but not do a p4merge right afterwards?

Well, perforce doesn't *require* you to do the resolve right away, but I 
can't think of any use case where you would want to do something after 
the integrate but before the resolve.

-- 
Matthew
GDRLaH - Grin, Duck, and Run Like a Hippo! :-)