[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: subversion/subversion/libsvn_wc status.c Makefile.am wc.h

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-10-26 15:04:52 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.