On Mon, Jun 23, 2014 at 10:37 PM, Duncan Murdoch
> I think the official svn way to do it is by branching, but the trouble
> with that is that merging other people's trunk changes into the branch
> can be tricky unless done very frequently, and it's a lot of work if
> done frequently.
I really think this is the best method for you to use anyway.
You're worried about merging trunk changes into your branch being
tricky. But if this merge is tricky, then applying your patch onto
trunk will be equally as tricky.
If you don't want to merge from trunk to your branch, then don't. The
only real reason to do that, is to make your final merge from branch
back to trunk easier. If it makes your life harder, then don't do it.
Your final merge from your branch back to trunk will be no more
difficult than trying to re-apply your patch from some earlier point
on trunk. And it should be far less error-prone. With a real merge,
you get the benefit of using the history in a 3-way merge. You retain
the ability to revert your changes and start over. You gain the
ability to merge one or two revisions at a time, rather than one giant
merge, if it makes the merge easier. With branching, you can commit
any and all of your changes as soon as you are at a stopping point,
regardless of whether or not it works, then you can "svn switch" your
working copy to take a look at an unmodified trunk.
I really cannot think of any advantages of using a patch if branching
is a possibility. The only reason I know of for using patches is if
you do not have write access, or if some change management process
prevents you from committing anything right now.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-06-24 17:09:20 CEST