Renaming trunk and then reintegrating from branch to new trunk name
Hi All Suppose trunk has been merging to branch. would renaming a trunk (trunk name change) causes an automatic change in the svn:mergeinfo of a branch so that merged mergeinfo list and eligible merge info list remains intact (from the branch perspective) ? Then when branch needs to reintegrate to the new renamed trunk, would it work because mergeinfo is pointing to old trunk name from branch perspective ? Thank you.
Re: Renaming trunk and then reintegrating from branch to new trunk name
Guten Tag Z W, am Dienstag, 7. Mai 2013 um 09:15 schrieben Sie: Suppose trunk has been merging to branch. would renaming a trunk (trunk name change) causes an automatic change in the svn:mergeinfo of a branch[...] No, Subversion doesn't magically generates changes in your working copy to unrelated folders, files or properties which you didn't change in any way. Then when branch needs to reintegrate to the new renamed trunk, would it work because mergeinfo is pointing to old trunk name from branch perspective ? I may be wrong but from my understanding reintegration looks from the target perspective, meaning if you want to reintegrate a branch into a trunk, trunk is checked for all versions from the branch which may already have been applied. That's way TortoiseSVN e.g. gives an error if not all changes from trunk have been merged into the branch after it's branching. After renaming the trunk you could merge the rename as record only to your branch and should be able to reintegrate afterwards. How that works of course depends on the changes between your new trunk and the branch to reintegrate. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: trunk naming best practice question
On Tue, May 7, 2013 at 12:14 AM, Z W mpc8...@gmail.com wrote: Hi Geoff Thanks for responding. So one would not make builds on trunk directly ? That would depend partly on your tools and workflow. Daily tags are good for providing a more human-friendly reference name to pass between developers and QA if builds are done manually.However a tool like jenkins can be configured to automatically do builds (and perhaps some testing) after every commit on the trunk and it has its own concept of numbering the builds. -- Les Mikesell lesmikes...@gmail.com
RE: trunk naming best practice question
For the trunk, what's the common practice to name a version of the trunk? We have a trunk and it's not ready for branching. We also feel that we need a more specific name for the trunk than what we have now called version=trunk. However, we can't be specific since we don't know what the branch name would be while at the same time, we need to perform daily builds for QA testing. What's the best practice in use with SVN ? Really, it's about whatever works best for you. We no longer use the name trunk on our projects. I guess it works ok if you branch for release... but that wasn't working for us. So, instead of using trunk we use the version number... so in our project you would see... /ProjectName /v1.0.0 /v1.1.0 /branches /feature1 /feature2 /tags Our procedure is to only merge up versions. We build and release from out version path [branch]. Feature branches are created for items that will take more than a day or more than one person is working on it. We fix bugs in the lowest version number that we are still supporting and merge that fix up all the way through our non-released dev version. This also helps us a lot with our build server, because we had to constantly redefine what was in the trunk working copy. This way creating a build project for a new release is much easier... we svn copy the version to the new release version, update the cruise control.net config file that is in the project folder with the new version number, checkout the new version path to the build server, update the ccnet.config root config to point to the new version. We also generally don't build from feature branches, but we could if we wanted to. However, the build scripts would have to be changed a bit since artifacts are copied to a folder based on version number atm. Once again, whatever works best for you. Using a trunk that was never the same version from week to week didn't work for us. We also were doing a lot of cyclic merges and needed a better way. BOb
mergeinfo between svn copied branches and merges
Hi All we have branchA we svn copy branchA to produce branchB branches A and B continues development and checkins branchA is merged to branch B continuously branchA finishes, tagged we then svn copy branchA to produce branchC we like to continue branchC merging to branchB we hear u clearly that the merge info are copied between branches we performed svn mergeinfo merged on branchB working copy with branchA we could see the correct list of merged rev numbers we performed svn mergeinfo eligible on branchB working copy with branch A; we see correct list of eligigle rev numbers we learn that these numbers are used by SVN to calculate what needs to be merged from branchB to branchA (-reintegrate) we performed svn mergeinfo merged on branchB working copy with branchC we see a new list (not including list of merged rev numbers from branchA) we learn that if we reintegrate from branchB to branchC, because those list of merged rev numbers from branchA are not there, SVN would not know those rev numbers changes already exist in branchC so SVN would try to reintegrate those list of merged rev numbers from branchA on branchC thus causing tree conflict. Would u agree ? How do we best recover this situation such that 1- we dont lose mergeinfo information from branchA when trying to reintegrate from branchB to branchC 2- no tree conflicts when performing reintegrate from branchB to branchC Thank you.
RE: mergeinfo between svn copied branches and merges
From: Z W [mailto:mpc8...@gmail.com] Sent: Tuesday, May 07, 2013 11:53 AM To: users@subversion.apache.org Subject: mergeinfo between svn copied branches and merges we have branchA we svn copy branchA to produce branchB branches A and B continues development and checkins branchA is merged to branch B continuously branchA finishes, tagged we then svn copy branchA to produce branchC we like to continue branchC merging to branchB we hear u clearly that the merge info are copied between branches we performed svn mergeinfo merged on branchB working copy with branchA we could see the correct list of merged rev numbers we performed svn mergeinfo eligible on branchB working copy with branch A; we see correct list of eligigle rev numbers we learn that these numbers are used by SVN to calculate what needs to be merged from branchB to branchA (-reintegrate) we performed svn mergeinfo merged on branchB working copy with branchC we see a new list (not including list of merged rev numbers from branchA) we learn that if we reintegrate from branchB to branchC, because those list of merged rev numbers from branchA are not there, SVN would not know those rev numbers changes already exist in branchC so SVN would try to reintegrate those list of merged rev numbers from branchA on branchC thus causing tree conflict. Svn will implicitly know about the rev numbers from branchA because branchA is a subset of branchC. Go here http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata and read Natural History and Implicit Mergeinfo. In this case, all you should have to do is: a) merge branchC UP to branchB b) merge --reintegrate branchB DOWN to branchC. Step a) will pick up any branchA changes (because all of branchA is a subset of branchC.) If you did additional work on branchA *after* creating branchC, then you would need to: a) merge branchA UP to branchB, b) merge branchC UP to branchB, c) merge --reintegrate branchB down to branchC.
