When to merge into a branch from trunk?
From: Giulio Troccoli <giulio.troccoli_at_uk.linedata.com>
Date: Thu, 20 Aug 2009 16:09:40 +0100
We have been using Subversion for few years now, without using any branches or tags, as our development process didn't need them (this is not strictly true, as we do use a sort of branch but not with the usual meaning on this ML).
Anyway, recently one of our project manager asked me if it was possible to create a branch of trunk for a project that we will not delivery for the next release. Since he wants to start development as soon as possible this seemed a good idea. I told him to wait until I upgrade Subversion to 1.6.4, which was last Tuesday, so that we can take advantage of merge tracking.
Now I'm trying to set up this thing and I have some doubts on when to merge the changes from trunk into the branch. My initial idea was to do it in the post-commit hook: every change to trunk will be automatically merge into the branch. When we release our latest version we can merge the branch back to trunk and, because of merge tracking that would be a single line command.
However, how to cope with conflicts that may arise from the automatic merge from trunk to the branch?
So I thought I could send an email to the developers who just committed the changes to trunk with exact instructions on how to do the merge. But that leaves it up to the developer not only to do it but also when to do it. I wouldn't be very happy with this as I'd like the merge to happen as soon as possible to avoid more changes to the same files and thus more chances of conflicts.
So, I think the process is clear and straight-forward: any changes to trunk must be merge into the branch. I'm just having some troubles implementing it.
Any suggestions, or comments?
Giulio
Linedata Services (UK) Ltd
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
|
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.