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
Received on Mon Jan 9 16:14:55 2006