On Fri, Mar 6, 2009 at 20:29, Geoff Gerrietts <ggerrietts_at_gmail.com> wrote:
> I've done a couple days worth of web searching, and trolled through
> list archives, and I've found nothing. I apologize if a poor search
> strategy has led me to repeat a common question.
>
> First, the setup: I have inherited a subversion repository and the
> associated software project(s) that live inside it, from my
> predecessor in my current position. When I took the position, handoff
> was minimal, and I had a reasonably lengthy list of software and
> systems issues that required immediate attention. The repository is
> structured in a basically correct fashion, but the circumstances of my
> early workload have led it somewhat astray. Let me be more concrete.
>
> The repository is set up like so:
>
> project/trunk
> project/branches/r1
> project/branches/r2
> project/branches/r3
>
> This is all straightforward enough. However, when I came on, r3 was
> running in production. Both r3 and trunk contained changes after the
> branch point. I knew r3 plus some amount of local filesystem delta was
> stable, but I had no idea what lived in trunk, nor whether it would
> even produce an operational system. Consequently, r3 has been used as
> a de facto trunk since that time, with all changes representing a
> delta from that point. I've been operating in that fashion for some
> time, because it's quite simply difficult to budget the kind of time
> required to review all the changes that would need to merge, and the
> risk such a big merge would imply is too large for me to successfully
> manage.
>
> Now I'm looking for a better way. I'd like to make r3 my new trunk,
> and retain the historical trunk only as a point of reference. But I'm
> really not sure how best to do that. Muddling about, I came up with
> two possible solutions. I'm not sure either is the best solution, but
> both represent a significant improvement over trying to manually
> reconcile the merge.
>
> Possible solution one: do an svn export of r3, and create a new
> project2/trunk and associated folders. This has the disadvantage of
> dissociating the project's history from the new trove of files, but it
> would work, and is clean.
>
> Possible solution two: do svn move project/trunk
> project/branches/history, then svn cp project/branches/r3
> project/trunk. This has the advantage of retaining the history, albeit
> in a somewhat tangled fashion, since "trunk" actually refers to two
> separate development lines, depending on which revision you're looking
> at.
>
> Can someone suggest a third alternative that might solve this problem
> more elegantly? Is one of these solutions preferred?
>
> I would appreciate it if replies would copy me directly; I'm not a
> list subscriber, and while I will attempt to follow the thread in the
> mailing list archives, I would hate to miss any feedback.
>
> Thanks,
> --G.
>
Use the second alternative as it preserves history. Yes, the history
becomes a little tangled, but I don't think that will cause you any
great troubles down the road.
// ben
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1278885
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-06 21:45:46 CET