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