[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: yet better rename approach?: (was RE: rename overwrites code: this a reasonable interim solution?)

From: Justin Johnson <justinjohnson_at_gmail.com>
Date: 2007-04-27 17:51:36 CEST

On 4/27/07, Irvine, Chuck R [EQ] <Chuck.R.Irvine@embarq.com> wrote:
> A very low-tech approach would be to try to wait to do renames until
> there is only one active development stream. (Yuk! I know...). Or maybe
> wait until there are only two active releases, RN and RN+1, where RN is
> in production and there are mainly only bug fixes happening on it. Do
> your renames on RN+1 and manually apply bug fixes found in production to
> both releases.

This isn't an option for us. We have 5 concurrent releases at a time,
and renaming is a normal thing that needs to happen in any one of
them. While this may be insanity, the business requires it.

Making changes to svnmerge.py seems like the easiest and most
effective option to me. I'm hoping someone who has thought about this
more carefully can point out potential pitfalls or why this is more
complicated than I am thinking it is.

Justin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 27 17:52:12 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.