I have a somewhat different situation and have had to create a trunk after the fact. Before I got here, code from a VSS repository was imported into subversion. The problem was that no trunk was created and everything was in the root of the repository. The system used to build releases had code checked out and as code was approved, the version of the checked out code was switched to the new approved version on a file by file basis. I had to create a trunk from the initial import and then merge versions on to it. Finally, after about two months, the trunk was caught up with the versions that were on the build system. We have switched to branches containing the unapproved code by moving it from the root of the repository to a branch and then started creating project and release branches from the trunk. We still have many merge issues due to the way things were done and I expect it to continue this way until the branches that have old code on them propigate
through the process. Most times, we have to use the ignore ancestry as things have moved around since the trunk and branches were created and we get errors due to missing paths as well as 404 errors on the server.
Based on this experience, you may be better off merging the release to the current trunk as it may help reduce merge problems in the future. This would definitely be the case if your other branches were created from the initial trunk.
Thank you,
Chuck Holzwarth
________________________________
From: B Smith-Mannschott <bsmith.occs_at_gmail.com>
To: Geoff Gerrietts <ggerrietts_at_gmail.com>
Cc: users_at_subversion.tigris.org
Sent: Friday, March 6, 2009 3:44:59 PM
Subject: Re: re-trunking a project
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].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1279078
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-06 22:37:18 CET