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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1278638
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-06 20:44:44 CET