Re: merging projects
From: Thomas Lehmann <Iris-und-Thomas-Lehmann_at_T-Online.de>
Date: 2006-10-17 15:50:58 CEST Bob Proulx schrieb: private branch!Thomas Lehmann wrote:my question relates to merges: Every developer is working on a project, that means creating and modifying some files AND doing some commits at stable phases to be able to undo implementations - stuff not working as expected.Are developers working on the main trunk or working on a private branch? I meant "global" because the revision increases independent of being in main or a private branch!http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patternsEach commit forces a new revision and my question is how to handle merging all files relating to a project; I want to keep control about what to merge into the release version and what to keep in the development version!I will assume by this that the release version is on a release branch. (That does not yet say whether developers work on the main trunk or on a branch though, just that the release is on a release branch.) I don't understand your comment about global version numbers. Every commit does increment the repositories last commit revision. But that has nothing to do with merging commits to a release branch. Those are completely separate concepts. Yes - my choice - but it's important how much it costs to do so:You can merge whatever you want onto a release branch. You can merge everything. Or you can "cherry-pick" particular changes. It is all your choice. Example: 10 Developers are working more or less independently on their projects and they will continuiously merging into the development line to keep it up to date. At any time (maybe some months later) individual developers are told to merge specific projects into the release. Solutions: 1) Every project is a branch but that does also mean: corrections in the context of an issue tracker needing 2 hours of fixing and testing are also a branch - how many branches has to be managed then -> 20, 50, 100, ... 10000 -> Is this what we want to have? Advantage: It's much easier to find out what to merge (thanks to the help as explained by last mail) 2) Each developer removes temporary branches after committing and each revision until the deletion of a branch must be remebered! (so we can start individual merges) -> many work!!!! Hown about the tracking feature? Future enhancement for subversion or always client stuffSubversion does not do merge tracking. Therefore when you merge you need to manually keep track of what you have merged. (About this point someone will mention the "svnverge" script which attempts to track this with subversion properties. It seems to work for me in one direction only. Perhaps it will work for you. YMMV.)I've been working on clearcase before and there each "checkout" forces to select a kind of task the change will refer to. Merging later on you can select each individual task you like to merge to another location... Is this possible with subversion?Yes. But it is very flexible and all up to you. It is a little like asking if you can create files on disk for paricular purposes. Of course you can. like the script you told me? Yes - fine! It sounds reasonable (and the only practicable) but not the best solution I would think about!If you create a branch for every particular task then this would be very much as you describe. svn copy $URL/trunk $URL/branches/task-branch -m "Creating task branch." svn switch $URL/branches/task-branch . ...edit...test...edit...test... svn commit Now the problem is to merge those changes back into the main trunk. Did you note down the version when the branch was created? No? Then look for it in the log. svn log --stop-on-copy svn switch $URL/trunk svn merge -r564:579 $URL/branches/task-branch . svn commit -m"Merged task-branch changes r564:579 into the trunk." I think we can live with it (actually). Could you give a hint on how to reduce the amount of temporary branches? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on Tue Oct 17 15:50:54 2006 |
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.