On Aug 20, 2009, at 10:09, Giulio Troccoli wrote:
> 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?
You do want to merge frequently (maybe daily, maybe weekly, depending
on how much is going on with the trunk), but it's done manually by a
person, not automatically by a script. This person needs to review
the changes made by the merge (just like every developer would review
the diff of their working copy for any other change) before
committing. If a conflict occurs, it is because the incoming changes
touch on some of the same code that has been updated in the branch. I
would suggest that the person or persons who "own" the branch should
be the ones merging in changes from trunk. If they cannot figure out
what to do with conflicts, they can speak with the other developers
who originally made those changes on trunk.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385664
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-20 17:34:22 CEST