RE: Merging change sets for a production release,
Hi again - I have a follow up question, please. I had an helpdesk issue with 18 changesets attributed to it. It took a while to resolve all the issues - but I finally got there. I did a diff on one of the files and I noticed that in the revision that there was a conflict for that file - there was no mergeinfo recorded for that revision. Do I need to do a --record-only post merge when there is a conflict? As always - thanks, - Gavin. -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, 4 June 2013 06:08 To: Gavin Baumanis; users@subversion.apache.org Subject: RE: Merging change sets for a production release, -Original Message- From: Gavin Baumanis [mailto:gbauma...@cogstate.com] Sent: Monday, June 03, 2013 2:27 PM To: Andrew Reedick; users@subversion.apache.org Subject: RE: Merging change sets for a production release, Hi Andrew, Thanks for your response. I do everything but for the chaining of the revisions to merge in the same command. I tried it once (granted a long time ago) and it caused such an issue for me that after about 6 hours of swearing, I finally gave up and reverted the changes and did the merges one by one. At the time one by one allowed for individual merge conflicts - which made life a little easier. As for the other ideas, we do already only merge changes from trunk that are complete and have been given the appropriate release milestone. Our release process is already issue-based. Perhaps simply chaining the merge revisions is the answer? Yes, I would try the 'svn merge -c ...' changed merge again. Assuming you're using SVN 1.7, chained merges should be much easier. It is still an iterative process, in that if a merge conflict is encountered, svn will prompt you for what to do, then you fix the code, resolve the conflict, and re-run the merge command to pick up where it left off. You will probably want to use 'svn merge --accept postpone ...' to avoid the prompting. It's normally a good idea to save off your merge command so you can add it to the commit comment (or in case anything happens to your command line's history buffer.)
Merging change sets for a production release,
Hi Everyone, At the moment we do all of our work on /trunk and also have /branches/releases/1.0 When we have enough issues, we mark the ready / required issues with a new release milestone and I go about the task of merging the required changes from trunk to the release branch. Here is what I am currently doing, that is giving me some issues, and I am hoping someone might be able to see what I am doing wrong / have some advice / comments to better the process I am using. Let's assume that I have multiple completed issues ready to merge from trunk that will become the Changes from the last version. Let's also assume that I have multiple subversion commits per issue - sometimes ~20 commits can be assigned against an issue. Let's also assume that the very same files that have the required changes to go to the new release - have other, not-ready for release changes made to them too. The scenario seems pretty ordinary to me - but I could, of course, be completely wrong. Anyway, So I open the first issue, notice there are 3 commits assigned to this issue. The first commit has 3 files, I do a cherry pick merge from trunk for each of the individual files listed in the issue. (Ignoring the paths...) svn merge -c 1234 /trunk/myPath/myFile1.c /branches/release/myPath/myFile1.c svn merge -c 1234 /trunk/myPath/myFile2.c /branches/release/myPath/myFile2.c svn merge -c 1234 /trunk/myPath/myFile3.c /branches/release/myPath/myFile3.c I manually resolve any conflicts that I may have. I then open the 2nd issue and repeat the process above as required for the change sets listed in the 2nd issue. A problem I am having is that I tend to get a lot of Merge conflicts doing it this way. But my biggest problem and the purpose for this email is; I might have a quite a few helpdesk issues to create a new release from. The same file might be edited in numerous issues. I often find myself doing a merge of a revision number less than one I have already performed. (depending on the order that I do the issue merging, of course) And oddly to me - I find at times when this is the case that my initial merge to the release branch is negated / overwritten. I am certain that it is a usage issue - but short of somehow ensuring that I do all the required merges in order - which is simply just too difficult to achieve - I find myself constantly battling with ensuring that the release branch is updated with all that this is necessary. If anyone has any ideas I would be most grateful. - Gavin
RE: Merging change sets for a production release,
Hi Andrew, Thanks for your response. I do everything but for the chaining of the revisions to merge in the same command. I tried it once (granted a long time ago) and it caused such an issue for me that after about 6 hours of swearing, I finally gave up and reverted the changes and did the merges one by one. At the time one by one allowed for individual merge conflicts - which made life a little easier. As for the other ideas, we do already only merge changes from trunk that are complete and have been given the appropriate release milestone. Our release process is already issue-based. Perhaps simply chaining the merge revisions is the answer? -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, 4 June 2013 00:48 To: Gavin Baumanis; users@subversion.apache.org Subject: RE: Merging change sets for a production release, -Original Message- From: Gavin Baumanis [mailto:gbauma...@cogstate.com] Sent: Monday, June 03, 2013 12:31 AM To: users@subversion.apache.org Subject: Merging change sets for a production release, Importance: High At the moment we do all of our work on /trunk and also have /branches/releases/1.0 When we have enough issues, we mark the ready / required issues with a new release milestone and I go about the task of merging the required changes from trunk to the release branch. Is there a reason why you all are not doing Release Planning ahead of time? Here is what I am currently doing, that is giving me some issues, and I am hoping someone might be able to see what I am doing wrong / have some advice / comments to better the process I am using. Let's assume that I have multiple completed issues ready to merge from trunk that will become the Changes from the last version. Let's also assume that I have multiple subversion commits per issue - sometimes ~20 commits can be assigned against an issue. Let's also assume that the very same files that have the required changes to go to the new release - have other, not-ready for release changes made to them too. The scenario seems pretty ordinary to me - but I could, of course, be completely wrong. Anyway, So I open the first issue, notice there are 3 commits assigned to this issue. The first commit has 3 files, I do a cherry pick merge from trunk for each of the individual files listed in the issue. (Ignoring the paths...) svn merge -c 1234 /trunk/myPath/myFile1.c /branches/release/myPath/myFile1.c svn merge -c 1234 /trunk/myPath/myFile2.c /branches/release/myPath/myFile2.c svn merge -c 1234 /trunk/myPath/myFile3.c /branches/release/myPath/myFile3.c I manually resolve any conflicts that I may have. I then open the 2nd issue and repeat the process above as required for the change sets listed in the 2nd issue. Is each svn commit tied to an issue? Meaning, are all the changes in a single revision tied to an issue? You shouldn't need to merge individual files. Just do a 'svn merge -c 100,110,...,N svn_url' and let svn walk through the cherry-picked merges. A problem I am having is that I tend to get a lot of Merge conflicts doing it this way. But my biggest problem and the purpose for this email is; I might have a quite a few helpdesk issues to create a new release from. The same file might be edited in numerous issues. I often find myself doing a merge of a revision number less than one I have already performed. (depending on the order that I do the issue merging, of course) And oddly to me - I find at times when this is the case that my initial merge to the release branch is negated / overwritten. I am certain that it is a usage issue - but short of somehow ensuring that I do all the required merges in order - which is simply just too difficult to achieve - I find myself constantly battling with ensuring that the release branch is updated with all that this is necessary. If anyone has any ideas I would be most grateful. Change your process. Brick Wall Analogy: Imagine that trunk is a brick wall built with 100 bricks (issues.) You're only merging 80 bricks (completed issues) to the release branch. The 20 missing bricks can result in gaps in your wall that are structurally unsound, or could even result in bricks floating in mid-air due to dependency issues (supporting bricks/issues were not merged over.) It's a crazy, slow, and stressful way to build a wall. IMO, you have several problems: 1) A lack of release planning. You all don't decide on what's going into a release until after the work is done. Which means you don't take dependencies into account. You don't take development time into account which can result in continual merge conflicts since you are always having to skip over commits related to the long running work-in-progress issue. You wind up mixing an inordinate amount of complete and incomplete
Release branch merging.
Hi There everyone, I have trunk, branches and tags. (the default repo setup) VERY recently we swapped from continuous deployment to having a scheduled release strategy. We used to simply cherry-pick or even just OS copy the required changes from trunk to a special(to us) branch any change that needed to go to production. This special branch was ten simply copied to production. Now, we are trying to start the standard release strategy, Develop on trunk, Merge to a release branch, Create a tag. I genuinely cannot recall how we created the release branch; all I know is the symptoms of what I now face - and hope to correct. I did this; cd /repos/branches/releases/1 svn merge ^/trunk --dry-run And subsequently got a status report that everything was going to be a conflict. So I think it's safe to say that the releases branch was created by an OS copy and not an SVN aware operation. is there a pain-free way that I correct my repository to allow for successful trunk - release branch merging? I am thinking of; * Deleting the release branch; * Recreating the release branch at the revision that the release branch was originally created. * Re-merging the single trunk change that was merged to ^/branches/releases/1.0 Which should bring it to its current state - and match the 1.01 release tag. And hopefully now allow me to merge ^/trunk - ^/branches/releases - which should allow a more pain-free merge for the next release. Do I have that right? Is there something else I can do that would negate the requirement to recreate the release branch? As always - thanks for your assistance. Gavin 'Beau' Baumanis.
Re: Authentication realm
Hi Konstantin, Thanks for the reply. On 30/09/2011, at 5:31 PM, Konstantin Kolinko wrote: 2011/9/30 Gavin Baumanis gav...@thespidernet.com: Hi Everyone, We recently created a DNS entry for our subversion repository. Prior to this we just use the private LAN IP address to access the repo via http (Apache) Post the change to having a hostname to use I created a new branch - and used the host name to do this. Subsequently when I perform an svn update I a now prompted for username and password for the named instance of our repo. I did some reading in the good book. and used svn switch (svn switch old_IP_address new_HostName_Address at the root of my working copy. It should have been svn switch --relocate which is very different to usual svn switch (so that 1.7 introduces a separate svn relocate command to lessen the confusion). Just for future readers. It does not seem to be a problem here. You're absolutely correct. I did indeed use the --relocate switch - I just omitted it (accidentally) from my original post. svn info confirms that the repo address is now set to the hostname version of the URL. However I am still getting prompted for a username and password. If I enter the usual password - all is good... but the prompt is playing havoc without Continuous Integration scripts. What havoc? You should use --username and --non-interactive. I'll give that a try - thanks. The password can be are either a) taken from cached auth credentials (auth subdirectory in subversion configuration area) b) entered interactively. c) entered on the command line as --password. If you never connected that system, there may be no cached password. b),c) cache the password automatically, unless you use --no-auth-cache, (and I think they wouldn't cache it without a prompt on *nix systems where password is stored unencrypted). Another question is whether the server is accessed directly or through a proxy (and you'll need a proxy password). - servers file in subversion configuration area. Some more reading suggests that I might need to add a new authentication realm and users via; conf/svnserve.conf svnserve,conf is for svnserve, but you are using Apache HTTPD and all authentication is handled by Apache HTTPD. Subversion handles only authorization. I was hoping that I might just get some confirmation that is indeed what I need to do - before I go playing with the config scripts. As always - a big thanks for your help. Gavin. Best regards, Konstantin Kolinko For the purposes of helping out anyone who might visit the thread later, here is what I have done to get it working. I deleted the cached credentials from; ~/.subversion/auth/svn.simple/ I then performed svn update and entered in the correct username and password. The cached credentials were then updated (correctly) and my; scripts worked correctly. I have tried the --username / --non-interactive yet - but I will. Thanks again for the reply. Gavin.
Re: Authentication realm
Hi Bert, Firstly, thanks for the reply. It seems that deleting the cached credentials and recreating them, did the trick. I (obviously) didn't ever manually create the cache or edit it myself. I assumed that changing to the new URL would simply create a new credential set for that URL and was, thus, surprised when it kept asking me to authenticate with any svn operation. I don't know if that is expected behaviour or perhaps a bug that needs some attention? As always - thanks! Gavin. On 30/09/2011, at 6:17 PM, Bert Huijben wrote: Passwords are stored per hostname (+realm), not per working copy like in your webbrowser, so using a different hostname requires adding a new username+password in your credential cache. Storing it in a different way would allow tricking subversion to send the username and password to any other server… Bert From: Gavin Baumanis [mailto:gav...@thespidernet.com] Sent: vrijdag 30 september 2011 5:14 To: Subversion Users Subject: Authentication realm Hi Everyone, We recently created a DNS entry for our subversion repository. Prior to this we just use the private LAN IP address to access the repo via http (Apache) Post the change to having a hostname to use I created a new branch - and used the host name to do this. Subsequently when I perform an svn update I a now prompted for username and password for the named instance of our repo. I did some reading in the good book. and used svn switch (svn switch old_IP_address new_HostName_Address at the root of my working copy. svn info confirms that the repo address is now set to the hostname version of the URL. However I am still getting prompted for a username and password. If I enter the usual password - all is good... but the prompt is playing havoc without Continuous Integration scripts. Some more reading suggests that I might need to add a new authentication realm and users via; conf/svnserve.conf I was hoping that I might just get some confirmation that is indeed what I need to do - before I go playing with the config scripts. As always - a big thanks for your help. Gavin.
Authentication realm
Hi Everyone, We recently created a DNS entry for our subversion repository. Prior to this we just use the private LAN IP address to access the repo via http (Apache) Post the change to having a hostname to use I created a new branch - and used the host name to do this. Subsequently when I perform an svn update I a now prompted for username and password for the named instance of our repo. I did some reading in the good book. and used svn switch (svn switch old_IP_address new_HostName_Address at the root of my working copy. svn info confirms that the repo address is now set to the hostname version of the URL. However I am still getting prompted for a username and password. If I enter the usual password - all is good... but the prompt is playing havoc without Continuous Integration scripts. Some more reading suggests that I might need to add a new authentication realm and users via; conf/svnserve.conf I was hoping that I might just get some confirmation that is indeed what I need to do - before I go playing with the config scripts. As always - a big thanks for your help. Gavin.
Ignore development changes.
Hi Everyone, I am just after some advice on how other people solve the following issue. I have a committed file. When it is deployed, it needs to be in a state (lets call it state 1) While testing code locally, it needs to be in some other state (state 2) Short of altering the code to read like; if on dev server have state 1 else have state 2 fi How can I have a local change, but have that change temporarily ignored? My initial thought is to use the svn:ignore But that brings about the issue of, out of mind out sight... and if I ever need to do real changes to that file, they won't be picked up in svn status. The answer is quite likely not even a SVN once - but perhaps a procedure / system one. I am open to any and all suggestions of how people might solve this issue for themselves already. And as always - thanks for any ideas you might have. Gavin Beau Baumanis
Re: Exclude a directory from a copy.
I am not sure if I am missing something or not... Possibly just this user error I have created a test repo as a test bed for the reintegration step. and created the following structure; /trunk /trunk/wanted /trunk/unwanted /branches I then did a WC-WC copy; svn copy trunk/ branches/myNewBranch Committed the change svn commit branches/myNewBranch -m'Blah' deleted the unwanted directory svn rm branches/myNewBranch/unwanted svn commit branches/myNewBranch -m'Blah' I then created a file in /branches/myNewBranch/fred.txt added, committed it. I then tried to merge my changes back; cd trunk svn update svn merge --reintegrate file:///Users/gavin/svn/repos/myProject/branches/myNewBranch and I got the following result; Awanted/fred.txt Dunwanted I tried with URL-URL copy - just to see if that made any difference - but it doesn't and upon reflection why would it? (Though I do take onboard that using a URL-URL copy/delete does away with the physical copy/delete upon my WC - which is a big time saver - because the unwanted directory contains something like 50,000 tiny files - and that is a time consuming couple of operatiojns) I also understand that unwanted is being deleted from trunk - because it is a difference between the branch and trunk at the time of the merge. I can simply revert the delete before commit svn revert trunk/unwanted svn commit -m'reintegrated from myNewBranch@xx to trunk' and everything is as I would want it to be.. Initially I thought I would check if there was some little gem to be used that would do it without me having to the extra work of manually; * Deleting the unwanted directory from myNewBranch * Reverting the delete in the trunk after reintegration. The URL-URL copy does away with the requirement of having to wait for the copy, then deletion of thousands of small files that make up the unwanted directory's contents. - so that's a great step forward in efficiency right there! Finally, I am fine with having to do it, myself... I just thought I would see if there was a better way (internal to svn - all in one / special) first. You never know what gems are hiding in there - if you don't ask. As always - a big thanks for the assistance Gavin Beau Baumanis On 23/06/2011, at 10:48 PM, Daniel Shahaf wrote: Konstantin Kolinko wrote on Thu, Jun 23, 2011 at 11:48:46 +0400: 2011/6/23 Gavin Baumanis gav...@thespidernet.com: Hi there everyone, I am just wondering if there is a short-hand way of excluding a directory from a copy? I am wanting to create a branch from the trunk - but omit a specific directory from the copy as it contains about 1GB of binary data that are not required for the work that will be occurring in the branch. I can manually do it, by doing a WC-WC copy and then simply deleting the sub-directory that I don't need, prior to committing the branch. But I thought I would ask if there was a smarter and more efficient way to do it first. Copying 1 GB takes time... You can 1) create URL - URL copy, then do svn delete URL as a separate commit 2) do not delete the unneeded subdirectory, but either do svn switch (should preserve unmodified data in place), or a sparse checkout I think that both action in 1) should be possible to do in one commit using svnmucc program - but I have never used it. svnmucc -m logmsg cp HEAD $U/trunk $U/branches/foo rm $U/branches/foo/subdir But actually I suggest to do it as you suggested, with 'svn rm URL' as a separate commit, which is then 'merge --record-only'ed to trunk. (assuming it's a branch intended for reintegration) Best regards, Konstantin Kolinko
