AfterShock wrote:
> So if I understand correctly, you're suggesting merging every "safe" change
> from trunk to branch every time any change is made, throughout the whole
> development cycle, OR, retrospectively going back through all the changes
> and merging the safe ones over 1 by 1. I have a few questions about this
> method:
>
> If I make an unsafe change for testing to the trunk, then I make a 2nd
> unsafe change to that file, then testing verifies that the file is now safe,
> I need to go back and merge both changes to the branch - I can't just merge
> 1 change. I don't know if this becomes tricky with many changes - is it easy
> to merge a commit along with all previous changes to that file since
> revision X?
>
> For example, this means that even if only 1 file has been changed (and we
> change it once a day for 150 days), I need to merge 150 changes rather than
> just adding 1 file, which seems kinda wasteful to me - if there's a way
> around this it would be much appreciated.
Yes, you need to merge all revisions you want to have on the stable branch.
Merging itself is easy, either use the merge wizard (right-click on your
working copy of the stable branch, choose "merge") or from the log
dialog (select the revisions from trunk you want to merge to the stable
branch, right-click, choose "merge revisions to...", then select your
working copy of the stable branch as the target).
> If I use this method (retrospectively going back and merging all the changes
> across to a stable branch), I've got around 600 commits to go through and
> merge - it would certainly be helpful if I could cut that number down by
> removing commits that are changing the same file (and by merging the highest
> commit, it merges all commits to that file since revision X, and then
> removes those commits from the list to parse).
No, you don't have to remove any commits! Always merge all the revisions
which have changes that you want to have on the stable branch.
> I don't suppose there is a method of merging commits into one commit? E.g.
> revision 9238 is feature X, 9245 is fix for feature X, 9249 a tweak for
> feature X, then merge all 3 of those commits into revision 9249? Something
> that could be done along the development process, tagging a commit as part
> of an ongoing feature. (this would also make viewing version history /
> feature tracking a lot easier rather than being spammed by various bugfixes,
> feature tweaks, balance tests, etc)
After the merge, your working copy of the stable branch has all the
changes merged into it. But those are now simple modifications (shown
with the 'modified' overlay) in your working copy. You can now commit
all those merged changes in one commit.
Maybe you should read the docs about merging to understand the concept.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=993835
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-27 20:04:09 CET