A forum for technical support discussion related to Fogbugz.
We've made a few modifications to our FogBugz installation. I want to upgrade to the new 4.0.33.
I have our FogBugz installation under source control (SVN). I guess I should have thought more about this process before now, but I kinda just thought, "It's under source control, upgrading and merging our changes will be easy," and I put it out of my mind. Now that upgrade time is here, I can't think of how best to do this.
Does anybody have thoughts on this?
Friday, December 23, 2005
Hmm, yeah. I was kinda hoping there would be a more source-control-centric process that essentially did what you describe. Something involving branches or tags or whatever.
Maybe I have to do this manually this time and then really think about how to organize this better for next time?
Friday, December 23, 2005
Here's how I'd do it from scratch, without thinking about branching and merging in SVN:
1. Put previous version of FB into the version control
2. Check that out into two working copies (A + B)
3. Modify A with your own mods
4. Put the new version of FB into B
5. SVN Commit B
6. SVN update A
Step 6 will automatically merge the new version of FB into your mods.
If you never commit from 'A', then you can repeat 4,5,6 everytime there's a new release.
Of course 'modify' can mean 'copy all my modified files (which I saved carefully somewhere else) over the top of a clean check-out'
Anyway, I think that will work, though I haven't tried it. Obviously be careful if you're copying chunks of WC around that you don't move the .SVN directories inadvertently.
Friday, December 23, 2005
For your next time, you might be interested in "vendor branches", see http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-4
(from the free online book "Version Control with Subversion", a rather excellent read for any developer using or administrating SVN)
Thanks for the help and pointers. I probably wouldn't have figured this out without your guys' responses.
I'm going to post exactly what I did to solicit comments. Maybe somebody else will find this useful.
This may be more thurough than necessary:
0. Commit all changes so that the head revision of your trunk is the latest.
1. Duplicate the installed FogBugz working copy. You'll need this in step 10.
2. Create a new folder named "release". Checkout (using TortoiseSVN popup menu) an unmodified 4.0.31 working copy into this new folder. I happened to have 4.0.31 unmodified, because I checked-in a clean 4.0.31 before making any mods. Next time I'll be able to directly checkout from the vendor branch...
3. Create a "vendor" branch in the repository from the "release" working copy and switch the "release" working copy to this new branch. Next time, just check out the latest "release" working copy from the vendor branch.
4. Duplicate the release working copy folder. You'll need it in step 7.
5. This step could use some improvement. The aim is to delete the installed FogBugz working copy folder and rename the release working copy folder to "FogBugz" so that the 4.0.33 installer will install into the release working copy folder. I don't know if it would be OK to stop the web server, etc. at this point (before using the FogBugz installer), to make it possible to just delete the FogBugz folder, so I just replaced everything I could in the FogBugz folder with stuff from the release folder (including .svn folders!), essentially doing the delete and rename.
6. Run the 4.0.33 FogBugz installer and install.
7. The installation will clobber (delete) .svn folders in the FogBugz working copy. Go through the installed FogBugz working copy folder (now at 4.0.33) and copy from the release working copy folder (at 4.0.31) any missing .svn folders. Most of them are missing.
8. On the working copy, do a "Check for Modifications" from the TortoiseSVN popup and check the "Show unversioned files" box to see what new things have been added. Add these new things. I think there was one new file - can't recall.
9. Commit the working copy. The vendor branch now has 4.0.33 without modifications.
10. Merge the release branch into the trunk. Right-click on the copy of the FogBugz working copy created in step 1 and choose Merge from the TortoiseSVN menu. In the merge window you want to set "From" to the head revision of the trunk and "To" to the head revision of the vendor branch you just committed. Do a dry run to make sure it's all set right. Merge. The merged working copy is now 4.0.33 with your mods. Commit the merged working copy into the trunk.
11. Replace the installed FogBugz folder with the merged working copy. This is like step 5, in that you can't just rename or delete the FogBugz folder.
12. Clean up. I had lots of copies of FogBugz folders to delete.
I would really appreciate comments on this. Especially with regard to steps 5 and 11.
Hmmm... somewhere in there our mods didn't make it.
A comment on step 7. The installer doesn't delete anything, but the first thing it does is move your FogBugz folder to FogBugz.1 (or FogBugz.2, etc) and then install a new FogBugz folder.
So your .svn folders are still there, but now they are in FogBugz.1
>A comment on step 7. The installer doesn't delete anything,
>but the first thing it does is move your FogBugz folder to
>FogBugz.1 (or FogBugz.2, etc) and then install a new FogBugz
>So your .svn folders are still there, but now they are in
Step 10, the merge step, doesn't do what I thought/hoped it would. You end up with no mods. When I checked it, I was looking in the wrong place.
Ok, I had the merge "From" and "To" set wrong. Replace step 10, above, with this:
10. Merge the release branch into the trunk. Right-click on the copy of the FogBugz working copy created in step 1 and choose Merge from the TortoiseSVN menu. In the merge window you want to set "From" to the revision of the vendor branch you just committed (the one with all the changes for 4.0.31 to 4.0.33), and "To" to the head revision of the vendor branch. Do a "Dry Run" to make sure it's all set right. Do a "Unified Diff" to make sure your mods aren't being removed. If they are, something is set wrong for the merge. Merge. The merged working copy is now 4.0.33 with your mods. Commit the merged working copy into the trunk.
>Personally I would do it the way Will suggested as that
>makes the most sense to me.
Yes, that's easier to grasp for me too. I would have done it that way, but I want our mods under source control as well. This is really the only reason why a branch is necessary; you've got two different sets of changes to manage and bring together.
Once you get it all set up correctly (as I have now), it's pretty straight-forward. It's the initial, conceptualization part that's hard. What I mean is, it shouldn't be a struggle each time. I hope.
This topic is archived. No further replies will be accepted.Other recent topics