Summarizing a few different points about conflicts at once here:
1) Yes, the working copies knows when something is in a conflicted
state after an update, and "svn status" will show this. This
state is not determined by the presence of conflict markers in
the file, but by a flag/timestamp combination in the
administrative area. (Not only would conflict markers not work
for all kinds of files, but there are times when a file can
legitimately contain conflict markers even though there's no
conflict -- such as the .texi files that document how conflict
markers work, to choose a random example. :-) )
2) Subversion cannot use markers for all conflicts anyway, since
non-plaintext files can have conflicts too. In such cases, all
three versions of the file have to be available, and the user
has to be notified of the conflict (maybe they'll have a special
merge tool to handle it).
But beyond making all three files available, no special support
should be necessary. Subversion can warn the user if they
commit without seeming to have resolved the conflict (the
timestamp is the clue here), but it shouldn't be any more
insistent than that. Sometimes doing nothing *is* resolving the
conflict, after all.
3) For plaintext files, the conflict marker method is familiar
(and, at least to some, convenient). An alternative to it is
to apply the patch as usual and save the rejects in a .rej file
nearby, like patch itself does when driven manually. This is
also familiar to many users, and may be simpler to implement --
it's probably what I'll do first, but we probably still want to
at least give the option of using conflict markers at some
point.
The .rej way satisfies Branko's concerns about the working file
being left in an uncompilable state.
-K
Jim Blandy <jimb@savonarola.red-bean.com> writes:
> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
>
> > Jim Blandy wrote:
> >
> > >> I thought it should be possible for status to report that a file
> > >> is currently in conflict? After an update, of course. Oh, that would
> > >> be nice! Let's not have any ">>>>>>"'s in working copy files, let's
> > >> not have to update to see conflicts ...
> > >
> > >
> > > I'm 100% with you that CVS's conflict handling is not especially
> > > graceful. Not to contradict Ben's "that's after 1.0" point, can you
> > > suggest an alternate interface? How should it work?
> > >
> > > Keep in mind that, after a conflict has been detected, we need some
> > > system that forces the user to actually do the manual merge before
> > > committing. Otherwise, people (being people) will tend to go ahead
> > > and commit, and the conflicting change will just evaporate. The
> > > current system of marking up the file with <<<<<<, etc. is pretty
> > > effective, in that sense.
> >
> >
> > http://subversion.tigris.org/subversion-dev/current/msg00265.html
> >
> >
> > I think this would be quite enough, wouldn't it?
> > Along with the client forbidding commit with unresolved
> > conflicts, and maybe a --force flag, for which the user
> > would need apropriate privileges.
>
> So the process you propose looks like this:
>
> - svn update brings in the new version, and checks for conflicts.
> If there are no conflicts, it replaces the working copy with the
> merged text, and updates its base version. Done.
> If there are conflicts, it stashes the newer version with the WC
> metadata, and leaves the working file's base version unchanged,
> so the user can't commit it yet.
> - We have a new command (commands?) which try to do the merge,
> cat the new repo version, whatever. These command(s) know when to
> actually change the working file's base version, indicating that a
> commit would work now. (How can these commands do something more
> helpful than rcsmerge?)
> - The user edits the result somehow.
> - The user does the commit.
>
> This introduces an extra step into the process CVS uses now:
>
> - svn update brings in the new version, adding conflict markers if
> appropriate.
> - The user edits the result.
> - The user does the commit.
>
> I'm beginning to appreciate why CVS does things the way it does now.
>
> (It's worth noting that privileges are meaningless here. There's no
> way to tell whether a user has actually resolved the conflict, or just
> deleted the other person's change. In fact, for some conflicts, just
> deleting the other change is the right resolution. So the user can
> always get the effect of --force no matter what we do.)
Received on Sat Oct 21 14:36:12 2006