> -----Original Message-----
> From: Les Mikesell [mailto:firstname.lastname@example.org]
> Sent: Tuesday, April 10, 2007 2:27 PM
> To: Irvine, Chuck R [EQ]
> Cc: email@example.com
> Subject: Re: Code Loss!?
> Irvine, Chuck R [EQ] wrote:
> > I just read this in the SVN Book:
> > "...suppose that while working on your private branch, you rename
> > integer.c to whole.c. Effectively you've created a new
> file in your
> > branch that is a copy of the original file, and deleted the
> > file. Meanwhile, back on trunk, Sally has committed some
> > to integer.c. Now you decide to merge your branch to the
> trunk. ...The
> > merge operation has deleted the latest version of integer.c
> file (the
> > one containing Sally's latest changes), and blindly added your new
> > whole.c file - which is a duplicate of the older version of
> > The net effect is that merging your "rename" to the branch
> has removed
> > Sally's recent changes from the latest revision!"
> > Coming from CVS, I was happy to have rename and move functionality,
> > but now I'm not so sure.
> > I consider pretty serious: there is a known, predictable situation
> > that will result in code loss. I'd have to consider this a "defect"
> > and not a "feature". Does anyone know if this is being worked on?
> > Thanks
> The code is only "lost" as in "you have to work to find it",
> not lost as
> in gone. If you want the stuff that was on the trunk before
> your merge
> back, check that revision back out - or diff against it to see what
Well, you're right, it is retrievable, but the problem is you might
never know that the code got dropped until the problems surfaces,
perhaps as a defect in production. Then, after much pain, you isolate
the problem and resurrect the code.
It would be much better to get a conflict notification of some sort,
something like "rename of foo conflicts with change or foo".
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Apr 10 21:37:13 2007