Jonas, hi,
Well, I'm pretty new to the group, but I can give you a view of my understanding:
>1) Urgent bugfix need to be released
>Suppose three branches: the trunk (T), a bugfix branch (B) and a feature
>branch (F). Many people are working in F doing many changes. Now a
>critical issue is fixed in (B), checked, merged into (T), and released
>to the client. Now, to have the fix in (F) too, (T) is merged into (F).
>This might happen various times. Later, development in (F) is finshed -
>(F) has everything that is in (B) and (T) and additional changes and
>needs to be merged into (T). How can I prevent that fixes already in
>(B) and (T) are merged back again? Or is there no issue with it, since
>SVN simply normally recognizes that there is nothing to do?
In this exact scenario, I think you will be fine. Things get a little more
complicated when you start making changes to the changes merged into (T)
between the point where you merge them into (F) and the point where (F) is
merged back into (T). At this point the common ancestor will indicate that
the lines of the changes in (B) have changed in both (F) and (T) and that
they are different in both, thus a conflict will be flagged.
The perfect behaviour would be to have an auto-merge of the new changes in
(T).
The best practice reccommendation from me would be to put something like
the following as your comment when you first merge from (T) to (F):
Merge - <revision number>
<rest of comment>
Put in the revision where you are merging. Then, when you do the merge of
(F) back to (T), you can specify that revision number rather than the
common ancestor at which you branched.
Some tools are considering putting in this sort of functionality in
properties and automating it. Don't know where they are on this.
P4 will give you this?
>2) Branch with different features need to be merged partially
>Suppose you have two branches: The trunk (T) and a feature branch (F).
>For some reasons, not only one feature A is developed in (F), but
>another one B. After quite a while of hacking, the clients wants us to
>relase feature A, but _not_ feature B. So I have to merge parts of (F)
>into (T): exactly those changes that were part of feature A. Any
>chance? Later, also B is to be released, so I have to merge "the rest"
>of (F) into (T). How is this done?
Hmm... how do you sepparate the features? Unless you have some development
practice, eg the features are in sepparate files, or the features are
developed and committed by exclusively different users, or that each commit
contains the ID of the feature it is for. Lastly an absolute must; each
commit can only contain the changes for a single feature.
If you have any of the above, then you could use the log to identify each
revision that corresponds to a commit for one of the features, and apply
each one as a sepparate merge into the release. The rest of the changes
could then be merged in a single operation.
Having said this, this is incredably time consuming and error prone (if
they were developed in parallel, what chance that there is some dependancy
somewhere?). Better to get people into the practice of using a sepparate
branch if you want to do things like this.
Oh, one other thing. If feature B was much smaller than feature A, then you
could roll back the changes for B (merge from higher revision to lower) and
merge that to your release, then roll the changes over again.
Does P4 cope with this then? How?
>3) Changs need to be spread over active branches
>Sometimes we do some refactoring, which is done in a separate branch
>(R), which, after everything is finished, needs to be merged to all
>other branches (say (B), (F1), (F2)) that are currently used, and later
>into the trunk (T). So the first "working branch" merged into (T) will
>incorporate the refactoring there. What about later merges? Will they
>fail? Will SVN recognize what happens?
Hmm... never tried. Don't see any problems other than those discussed for 1
above, but again, not tried it.
Again, is there some special support in P4 for this?
Interested in your comments on performance... in what operations is P4
faster. It shouldn't really outperform SVN on large commits.
Looking forward to the other suggestions that come in on this...
Thanks
Malc
-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 14 14:21:26 2004