>>> On Thu, Apr 12, 2007 at 4:57 pm
>"Morel, Jacques" <Jacques.Morel@sabre-holdings.com> wrote:
> As an example, my team is dealing with that very issue right now:
> We have 2 active branches: the release branch and trunk. ....
This is exactly the kind of problem we will have soon in our shop, if we
don't find a solution, as we are planinng paralle development of features,
using task branches, stabilization branches, and release branches, with
a lot of merging going on, which creates many scenarios where this is
a problem (as described in detail on another thread).
But the data loss can happen in even a very simple, non-branching
scenario, as I'll describe below.
> I believe this is what Chuck is talking about when "thou shalt not lose
> code".
> <snip>
> To be fair svnmerge does at least warn the user but it does by issuing a
> non threatening "skipping <file>" output message too easily discarded.
It should be extremely difficult to cause code loss. Our shop didn't have
this problem with CVS either, but we avoided some refactorings because
CVS made them more work or problematic than SVN does (like losing
history). But now w/ SVN we have this new risk.
To duplicate data loss in a simple scenario involving two developers and
a single branch:
1) Developer A edits a file and checks in.
2) Developer B renames the same file on the same branch, and tries to
check in but gets an error that he is out of date.
3) Hmm, he thinks, I'd better run an 'svn update' on the directory, and
does so, then reruns 'svn commit' without realizing that the update
failed to apply the edits to the renamed file.
4) Result: 2 local copies of the file: one with the old name (which is not
under version control but does have the edit from step #1), and one copy
with the new filename, which was checked in but does not have the edit
from step #1. Data is effectively lost.
Will Developer B notice the problem? Could he have handled the original
error message better, about being out of date? Maybe, if he is aware
of the issue and very alert. But it's much better and safer to make it
extremely difficult to cause code loss.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 01:25:32 2007