> >
> > If I had heard that the current implementation of renames can and
> > probably will lead to code loss (from the latest revision), my
> > reaction would have been much different. To me, probably the first
> > rule of source code management is "thou shalt not lose code".
>
> No source control mechanism can prevent code loss at the
> latest revision
> if someone commits changes that cause it. What the revision
> mechanism
> provides is a way to get back any older version ever committed.
True, but only if user misuses the tool. However, if you use the tool
correctly, which we are, you should NOT lose code. I used and supported
CVS for two years with a team of over 50 developers; I never once saw
code loss.
>
> > At this point we have adopted it as our standard tool, moved
> > applications to it, bought 24x7 support, etc, so we are
> committed and
> > will have to figure out how to avoid losing code.
>
> Develop on the trunk and branch for releases. That should make it a
> rare case that you ever have to merge refactoring-type
> development work
> back from a branch to the trunk where someone may have concurrently
> added things to a file that has been renamed/replaced on the branch.
>
Unfortunately for us, we frequently have several releases in development
concurrently. Say, production is at release R1. We might have two or
more (e.g. R2, R3, etc) other releases in the development pipeline. So
we merge thus: R1 -> R2 -> R3.. -> RN
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 00:14:28 2007