After an hour or so of reading tutorials and trawling Google I'm still stuck on something.
Suppose I want to call my current software tree "v1", and create a copy to become "v2". The software is a PHP web library and basically the purpose of v2 is to start removing all the old PHP3/PHP4 compatibility code, and tidy things up, thus breaking backwards compatibility.
I think I start with something like: svn copy -m "v2" <svnrepo> <svnrepo>/tags/v1 svn copy -m "v2" <svnrepo> <svnrepo>/tags/v2
My current code is already in a directory ~/mylib/v1, and I want to keep that as it is (several apps on the server are using it), and checkout v2 directory ~/mylib/v2; new apps will start to use that version.
So far so good. Where I'm stuck is how to make sure that ~/mylib/v1 stays on the v1 branch so I can continue to fix bugs and add features (unlikely but possible) to it if I need to, and ~/mylib/v2 similarly stays on the v2 branch. Both will have regular commits to their respective branches, and I may want to merge fixes from v1 into v2 (and vice versa). In other words v1 will become v1.0.1, v1.0.2, ... and v2 will independently become v2.0.1, v2.0.2, ... whilst sharing common history and allowing me to migrate some changes between branches.
I think all I need to do is make sure in each directory I switch to the right branch and then any commits/copys will apply to that branch only, but everything I've read talks in terms of the branch being temporary while a new feature is added, rather than permanent with the intention of maintaining v1 and v2 as separate versions going forward (and no doubt spawning v3 from v2 at some point down the line).
Before I go too far I just want to be sure I'm on the right track.
On 05 Jul 15:33, Mark Rogers wrote:
After an hour or so of reading tutorials and trawling Google I'm still stuck on something.
Suppose I want to call my current software tree "v1", and create a copy to become "v2". The software is a PHP web library and basically the purpose of v2 is to start removing all the old PHP3/PHP4 compatibility code, and tidy things up, thus breaking backwards compatibility.
I think I start with something like: svn copy -m "v2" <svnrepo> <svnrepo>/tags/v1 svn copy -m "v2" <svnrepo> <svnrepo>/tags/v2
My current code is already in a directory ~/mylib/v1, and I want to keep that as it is (several apps on the server are using it), and checkout v2 directory ~/mylib/v2; new apps will start to use that version.
So far so good. Where I'm stuck is how to make sure that ~/mylib/v1 stays on the v1 branch so I can continue to fix bugs and add features (unlikely but possible) to it if I need to, and ~/mylib/v2 similarly stays on the v2 branch. Both will have regular commits to their respective branches, and I may want to merge fixes from v1 into v2 (and vice versa). In other words v1 will become v1.0.1, v1.0.2, ... and v2 will independently become v2.0.1, v2.0.2, ... whilst sharing common history and allowing me to migrate some changes between branches.
I think all I need to do is make sure in each directory I switch to the right branch and then any commits/copys will apply to that branch only, but everything I've read talks in terms of the branch being temporary while a new feature is added, rather than permanent with the intention of maintaining v1 and v2 as separate versions going forward (and no doubt spawning v3 from v2 at some point down the line).
Before I go too far I just want to be sure I'm on the right track.
1) Branches are *not* tags (although svn treats them the same) 2) tags *never* *move*, they are a snapshot of code at the time the snapshot is made 3) you want to create a *branch* for v2. Though, I suspect that actually, you've currently got a trunk, and v2 is probably the main development line, so should be trunk, ergo, you actually want to create a v1 branch for legacy raisens. 4) svn is absolutely completely totally crap at merging at the best of times. 5) v1.0.1 would be a tag from the v1 branch
Hope that clears the mindset. These days I use git, and this is really trivial in git :)
On 05/07/11 16:35, Brett Parker wrote:
- Branches are *not* tags (although svn treats them the same)
- tags *never* *move*, they are a snapshot of code at the time the snapshot is made
- you want to create a *branch* for v2. Though, I suspect that actually, you've currently got a trunk, and v2 is probably the main development line, so should be trunk, ergo, you actually want to create a v1 branch for legacy raisens.
Good point. Yes you're right: v2 will be trunk.
- svn is absolutely completely totally crap at merging at the best of times.
To be honest I think the idea of merging between branches is a nice-to-have rather than a must-have. In other words I wouldn't want to mess things up and close that door, but I'm not expecting to get much from it.
- v1.0.1 would be a tag from the v1 branch
Assuming I'm in the v1 directory and that has previously been switched to the v1 branch, so "svn commit" would update the v1 branch, etc.
Is there a way to create the tag v1.0.1 without using copy? What I'm looking for is a way to say "commit the current code as v1.0.1 off the current branch" without having to specify what the current branch is. Having to specify it seems much more error prone than saying "this one"!
Hope that clears the mindset. These days I use git, and this is really trivial in git :)
I would much prefer to be using git (which I have even less experience with) but the support for Windows users seemed to be lacking when I looked at it, and although I'm on Linux for everything these days that's not true of others I work with :-(
Hope that clears the mindset. These days I use git, and this is really trivial in git :)
I would much prefer to be using git (which I have even less experience with) but the support for Windows users seemed to be lacking when I looked at it, and although I'm on Linux for everything these days that's not true of others I work with :-(
Mercurial / hg is a nice alternative to git which has pretty good Windows support - there is a TortoiseHg explorer client and it has support in Eclipse etc.
Worth a look.
Peter.
On 05/07/11 17:50, samwise wrote:
Mercurial / hg is a nice alternative to git which has pretty good Windows support - there is a TortoiseHg explorer client and it has support in Eclipse etc.
I'm certainly interested to know which VCS would best suit me, but that's as an aside. We have a number of apps already in svn and a handful of users using them via TortoiseSVN. They're all pretty basic configs: it's really just being used as a backup of the code, and each place it's used is only really interested in the "latest" version unless it has to rollback because there's a problem, but each set of code is only used in one place so maintaining multiple versions isn't an issue.
I'm trying to make better use of svn in places it can actually bring some value, and whilst ditching it in favour of git/hg/other isn't out of the question I'm going to need a good reason to convince people to learn something new.
OK, I've got myself into a bit of muddle here.
Following some advice I found online, I started with: cd ~/mylib/v1 svn mkdir <svnrepo>/branches svn mkdir <svnrepo>/tags svn copy . <svnrepo>/branches/v1 svn copy . <svnrepo>/tags/v1.0.0
cp -a ~/mylib/v1 ~/mylib/v2 cd ~/mylib/v2 svn switch <svnrepo>/HEAD svn update
At this point my branches and tags directories got downloaded into my v2 directory (creating ~/mylib/v2/branches/v1 and ~/mylib/v2/tags/v1.0.0). That's not what I was expecting at all!
If I explain what I'm trying to achieve a bit better maybe someone will make sense of this. I will have two or three servers where I will want the full svn repo, and I'll want to be able to edit and commit files in either the v1 or v2 branches and keep the the servers synchronised. I don't mind whether this is done independently from my v1/v2 dirs, or whether those v1/v2 dirs are just symlinks into the main repo.
I also need, on those same servers, for different apps to be "pointed" at the version of the library they're going to use, which in essence means being able to add the correct directory to my PHP config for the site as an include path.
And then, I need to be able to create new servers which checkout only the version of the library they need, because they'll be single purpose servers that won't need all the development versions and will be "fixed" onto the latest copy of one or other branch (or maybe even fixed on a specific tag, although that's less likely).
Is that possible, or am I looking at things completely wrong here?
-
Brett Parker -
Mark Rogers -
samwise