Joe Drew wrote:
>
> CVS had a (mis?)feature that aborted updates once the first conflict was
> found, exiting with an error code. Subversion doesn't do this, which is
> perfectly OK, but it also did away with the error code upon exit.
Hmm... It's a philosophical question. Is a conflict during Update a failure
of Update?
In some ways a detected conflict can be considered a failure of Update: the
resulting file is definitely unsuitable for use, rather than probably OK.
In other ways it's not a failure: the update did what it was intended to do,
and it is the user's responsibility to check the result. The automatic merge
performed by Update is only a best-effort attempt. Even if it does not detect
a conflict, there may nevertheless be a semantic conflict. For example, the
deletion of a variable merged with the addition of a use of that variable.
Therefore we cannot achieve an exit code that tells unambiguously whether the
update is "successful"; we can only say "definitely failed" or "maybe OK".
A conflict during Update is definitely a lower class of error than failure to
complete the update process (e.g. due to disk/network/data errors). Therefore
if we have an exit code for "update completed, but conflicts found" we would
probably want a different (higher) exit code for "update failed: not
completed". This would be analogous to the case of programs like "cmp" and
"diff": 0=same, 1=different, 2=error.
An alternative approach is to leave the normal behaviour of "update" as it is,
but add a mode in which only successful automatic merges are allowed. Any
detected conflict would result in failure of the command.
> svn's update behaviour is a problem for us in a couple of ways:
> 1. Update doesn't fail, so it's not always *obvious* (especially with a
> bunch of updated files) that something has gone wrong. If you miss that
> C, you could be screwed.
Right: I can agree that it may not be obvious, if the "C" appears within a long
list of output. Whether you're "screwed" is another matter; that term is
unspecific ( :-) ) and anyway, as I said above, you can get similar problems
without a "C" code, just not so often.
> 2. Update never reports that conflict again. You have to rely on svn
> status for that information.
That's by design: "update" reports only on what it is doing, not on the status
of files that it is not updating. I can see that that will take some getting
used to when it's not what you're accustomed to, but I don't see why you call
it a problem.
(I don't know whether Subversion will try to update an already-conflicted file,
or what it reports if it does so.)
> When re-training CVS users, this is a major stumbling block.
OK.
> Especially
> in nightly builds (automated or manual) that haven't noticed a conflict
> has occurred. Naive build scripts that assume svn update will always
> tell them if there has been a conflict (i.e., any build script that was
> originally developed for CVS) cause unforseen build failures since if
> your build aborted due to conflicts on Friday (leaving your working
> binaries intact), it won't fail on Saturday (and will try rebuilding
> everything, often resulting in either a build failure or some
> semi-silent bug you find weeks later).
I had trouble following that after the first four lines. A typical build sytem
based on GNU "make" doesn't suffer from those problems; if the build fails it
will fail each time you try it until you fix the error.
I think I understand now: your build system doesn't delete an output file or
otherwise mark it as needing to be re-built when it fails to build it, so, if
you try to re-build without modifying the source file, it uses the old output
file and continues to build the rest of the system with it. Thus you end up
with a partly-out-of-date result that may or may not build completely and, if
it does, will contain out-of-date code (hence the "semi-silent bug").
It sounds like that is purely a deficiency in the build system, and nothing to
do with Subversion. You can get a build failure from an undetected
("semantic") conflict just as you can with a detected conflict, or even just
with bad code checked in to the repository, so this is not really relevant to
the topic of discussion.
> Re-training CVS users to use svn status is a good idea, but a long-term
> goal. It'd be very nice if svn update:
> - reported loudly that updates (current or previous) resulted in
> conflicts; and
I think I would support adding a message at the end of "update" output that
says there were conflicts. I don't think I would support detecting and
mentioning previous conflicts.
> - returned an exit code of failure if that happens.
I think I would support adding a "conflicts are errors" mode of operation to
achieve this, rather than changing the default behaviour.
> Believe it or not, this is one of the biggest problems we've had in
> switching over to Subversion.
I suppose that's quite encouraging really, in that we can hopefully make this
not be a huge problem.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 9 12:52:10 2006