>We have encountered an issue with developing along the trunk and have
>realised that this methodology may not be a good fit for us.We are
>encountering many small projects being sent to production at different,
>staggered and even shuffled stages, where initial release dates suffer
That is an issue which occurred again and again on a major project I
worked on, albeit under CVS and it's hair tearing stuff, particularly
when a partial commit leaves the trunk or branch broken until Monday.
>We believe now that the best way to handle this would be to create a branch
>any time somebody starts a new project and let them do all their
>development on that branch. Then get them to merge back to the stable trunk
>at time their project is ready for prime-time.
There is no doubt. Creating branches to enable parallel and even
multiple branches to conduct disassociated development significantly
aids the development process, not just for groups but for single
Subversion's backend and network efficiency is such that you should not
feel encumbered to create branches and occasionally branches off
branches to ensure issues can be cleared up and working before being
merged back again. That's the sort of policy a group of people might
need to be made to agree on, to minimize the risk that a group accessed
branch or trunk will not be left in a broken state.
>The problem we are having directly atm is that we wish to branch off where
>our current trunk/head development is to a branch so that we don't lose any
>code, but then we also wish to take one of the previous branch/head's and
>turn that into the mainline stable trunk/head that we can then further
>merge back into.
>If I get a working copy down using tortoise (r41) we cannot then make that
>effectively become our trunk (> the previous trunk head of r100). When I
>then tried to commit that r41 to the head of the repository I got an error
>telling me that things were out of date and that I should do an update and
>I got an error of 106-1 or something to that effect.
OK, I think the process is achievable but importantly do things one step
at a time.
How does the following sound? (Someone can correct me if this wouldn't
1 Create a "NewTrunk" Branch from the revision r41 or whatever in the
project root and commit.
2 Progressively merge to the newtrunk just those changes you want to
retain that occurred on the trunk after the branch point (r41) and commit.
3 SVN rename Trunk to OldTrunk and commit
4 SVN Rename NewTrunk to Trunk and commit.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 8 12:52:24 2005