[kepler-dev] [Bug 4311] Build system appears to lock if there is a conflict upon update

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4311

--- Comment #10 from David Welker <welker4kepler at gmail.com> 2010-01-08 13:41:18 PST ---
A couple of things. First, there are two alternative things we could mean by
"fixing" this issue: (1) Print out the error so that the user can resolve the
issue manually. (2) Allow the user to interact with svn to resolve the conflict
while the update command is temporarily suspended.

Of the two solutions, (2) would be preferable in some situations (if the
conflict is easy to resolve). But it would be rather challenging, because you
would have to find a way to "come back" after the conflict is resolved. Keep in
mind that one way people resolve conflicts is by jumping into emacs or vi or
whatever. I am not enough of a UNIX maven to know whether the output you see on
these screens is part of the standard out stream or not. Is it possible to
suspend the update while the user has full rein to do whatever they like from
the command-line? Maybe it is, if there is a standard message (or messages)
that SVN gives when a conflict is resolved, I suppose one could monitor
standard out and resume only when that message is received. What if the user
decides to resolve the conflict in another command-line window? Then your
program will be suspended forever, and you wouldn't realize it -- until some
random time when the message that you are monitoring standard out for somehow
appears, and the "missing" update command unexpected resumes, doing who knows
what.

Further, is this really a desirable work process for many conflicts? Users may
need to investigate how to resolve the conflict. It could be a complicated task
unto itself and users might be switching back and forth between multiple
programs, making phone calls and writing emails to resolve the conflict. It is
possible that the update could be suspended for quite a while during this
phase, and the later modules are updated in a way that is incompatible with the
previous modules. In fact, this is a risk with any update now: it just isn't
likely, because the "ant update" command usually executes fairly quickly.

On the whole, I think there are many potential issues with trying to allow the
user to suspend the update while they try to figure out how to fix a conflict.
What if it takes a long time and therefore the modules are updated in
inconsistent states as a result? What if they resolve the conflict in a
different command-line window, thereby depriving the update command knowledge
of when the conflict is resolved? 

Do we really want to be mixing updates and resolving conflicts in one huge
process? Maybe, but it sounds like it may be more trouble than it is worth.

Approach (1) in contrast is fairly simple. The update fails. You fix the
conflict. You may or may not then choose to finish the update. When you do
finish the update, all of the modules that were updated before the conflict are
updated again, ensuring consistency. You are completely free to fix the
conflict in an entirely different command-line window than you do the update
and you are also able to use multiple command-line windows safely.

Yes, it is annoying when the command fails because you have to fix something
manually. But it is also annoying when the command is suspended and you have to
fix something manually. At least if the command fails, you have less issues
with consistency and the possibility of indefinite suspension -- and remember,
the indefinite suspension might be ended much later when you resolve a totally
unrelated conflict -- meaning that updates that you think are very undesirable
at that moment could occur without you expecting it.

Now, if I understand correctly, even if we go with solution (1) it has been
suggested that solution is not currently working, since there is some sort of
locking occurring and there is no output whatsoever indicating the source of
the problem. The update command just mysteriously stops working? Is my
understanding correct?

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.