svn update exit code with conflict

[Joe Drew <jo...@sidefx.com>]

Hi everybody,

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.

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.
2. Update never reports that conflict again. You have to rely on svn 
status for that information.

When re-training CVS users, this is a major stumbling block. 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).

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
- returned an exit code of failure if that happens.

Believe it or not, this is one of the biggest problems we've had in 
switching over to Subversion.

Joe

PS: Please CC me on replies.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn update exit code with conflict

[Ron <li...@rzweb.com>]

> I would much appreciate having an error code returned when a conflict 
> happens as well.  I think I emailed this to the list previously, but got 
> zero response.

I second that request.  An error return code on conflicts would help me a lot (if it's a compatibility problem, a flag to turn it on would work).

Ron

Steve Williams wrote:
> 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.
> 
> I would much appreciate having an error code returned when a conflict 
> happens as well.  I think I emailed this to the list previously, but got 
> zero response.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn update exit code with conflict

[Steve Williams <st...@kromestudios.com>]

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.

I would much appreciate having an error code returned when a conflict 
happens as well.  I think I emailed this to the list previously, but got 
zero response.

-- 
Sly


This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn update exit code with conflict

[Joe Drew <jo...@sidefx.com>]

Julian Foad wrote:
> 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".

That's OK, though. "Definitely failed" status is all that we encounter 
in the common case, because most of the time you're aware of the files 
you're working on, so when you do an update before testing & committing, 
seeing the G in front of the files you're working on tells you "Ok, time 
to do a tkdiff on those files again."

Unless I'm missing something and update does merging more often than I 
thought?

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

"screwed" is of course relative. :) It's fairly frequent that I hear 
curses first thing in the morning, though, because a manual 
update/rebuild cycle started the night before neglected the "C" in the 
long list of updated files.

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

It's a problem for two reasons:
1. CVS told you if there was a conflict for ever and ever amen, until 
you fixed it. People relied on that: if my update reported no errors, 
then my build is highly likely to go through.
2. Nightly build scripts can run into troubles, which I will elaborate 
on below.

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

Sorry for the difficult paragraph. I'll rephrase.

Our nightly builds tend to consist of a couple of distinct steps, each 
of which relied on the previous step to have completed successfully 
(where success = make's definition of success).

1. svn update.
2. make clean.
3. make.

Step 2 tends to also remove your working binaries.

If you rebuild once, and step 1 fails, you still have a set of working 
binaries that you can use while you're rebuilding after resolving the 
conflict. But if you rebuild multiple times (as happens on a weekend), 
and step 1 fails on, say, Friday, two things are likely to happen:
1. Your working binaries will be deleted (step 2).
2. Your build will fail.

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

Doing only one would be helpful, but doing both would be *extremely* 
helpful, in the "wow subversion doesn't suck" sort of way.

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

I might have been a bit hasty in saying that - our Windows developers 
tend to moan and groan about Subversion a lot. But that's the topic for 
a totally different mail.

Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn update exit code with conflict

[Julian Foad <ju...@btopenworld.com>]

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