[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 10.04.07 09:39:58, Matthew Woehlke wrote:
> 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).

I didn't yet look into kdiff3 but I'd like to have it as a plugin and
not as a separate app, so we may need to do more than just providing a
way of setting the filenames.

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

You get a file wich is in a conflict state and cannot be committed as it
is (until you do svn resolved). It will contains stuff like

>>>>>>>>> .mine
<<<<<<<<<
>>>>>>>>> r12453223
<<<<<<<<<

on the conflicts. So what the svn plugin would do is close to what
perforce does, just that it does this only when there's really a
conflict and not on every file...

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

Hmm, given that we will have "resolve" action anyway (as conflicts in
svn can happen on normal updates), I guess we can as well let the merge
be without the resolve. The backend can then update the state properly,
i.e. in perforce all files are marked as conflict or "needs resolve" and
the user can then select all files or specific ones to resolve...

Andreas

-- 
You will be married within a year, and divorced within two.