I know this doesn't belong here, but Im looking for some quick information:
I have the following structure:
branches/ tags/ trunk/
In my repository. Inside trunk is version 1 of our application. I want to start on 1.1 which is actually a major rewrite of almost everything.
So I create a 1.1 branch. and remove all files in the branch
Now, when I'm finished with the 1.1 branch, how do I merge it into trunk? can/do I just remove everything in trunk and merge the branch stuff down? The entire file structure is changing for version 1.1
Any insight would be appreciated :)
Eric Coleman
I know this doesn't belong here, but Im looking for some quick information:
Now, when I'm finished with the 1.1 branch, how do I merge it into trunk?
Read the SVN book, it covers this topic thoroughly.
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
I've read, and reread the svn book on branch / merging...
And I still don't understand what im supposed to do. I think I do this:
1) SVN Copy trunk to the new branch 2) checkout the branch, remove all files 3) put new files into branch, commit, etc 4) Delete files in trunk, merge branch to trunk
I somehow don't think that's right, but I honestly am not sure.
Eric Coleman
On May 1, 2006, at 1:59 PM, Aparajita Fishman wrote:
I know this doesn't belong here, but Im looking for some quick information:
Now, when I'm finished with the 1.1 branch, how do I merge it into trunk?
Read the SVN book, it covers this topic thoroughly.
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed."
- Sri Chinmoy | www.srichinmoylibrary.com
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 02/05/2006, at 3:23 PM, Eric Coleman wrote:
I've read, and reread the svn book on branch / merging...
And I still don't understand what im supposed to do. I think I do this:
- SVN Copy trunk to the new branch
- checkout the branch, remove all files
- put new files into branch, commit, etc
- Delete files in trunk, merge branch to trunk
I somehow don't think that's right, but I honestly am not sure.
Eric Coleman
Are you coming from CVS?
Luke Daley.
i've been using subversion for about a year, but I haven't ever bothered with branches / merging. It was always ok to just use trunk and we tagged releases...
Never had to take it any farther
Eric Coleman
On May 2, 2006, at 1:34 AM, Luke Daley wrote:
On 02/05/2006, at 3:23 PM, Eric Coleman wrote:
I've read, and reread the svn book on branch / merging...
And I still don't understand what im supposed to do. I think I do this:
- SVN Copy trunk to the new branch
- checkout the branch, remove all files
- put new files into branch, commit, etc
- Delete files in trunk, merge branch to trunk
I somehow don't think that's right, but I honestly am not sure.
Eric Coleman
Are you coming from CVS?
Luke Daley.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 02/05/2006, at 7:23, Eric Coleman wrote:
I've read, and reread the svn book on branch / merging... And I still don't understand what im supposed to do. I think I do this:
- SVN Copy trunk to the new branch
- checkout the branch, remove all files
- put new files into branch, commit, etc
- Delete files in trunk, merge branch to trunk
I somehow don't think that's right, but I honestly am not sure.
If you're really creating an entirely new branch with no files carried over, I would replace steps 1-2 with: 1) SVN mkdir the new branch in branches/ 2) Commit that (nothing to clear or checkout). 3) Continue as above...
But really, why not do this: 1) Delete trunk. 2) Move in new files. 3) Commit.
I don't see a need for branches if you're just replacing the entire system. If you want to keep the old one around, create a tag or branch for it _before_ you do the steps above.
I think your scenario is rather rare, in svn supported projects.
-- Sune.
Thanks for the information.... The reason is that:
This is a commercial product. We need to maintain the current release while we finish work up on the next version. The next one is the biggest update we've done since launch, and well, just don't want to get caught with our pants down.
Thanks everyone :)
Eric Coleman
On May 2, 2006, at 6:15 AM, Sune Foldager wrote:
On 02/05/2006, at 7:23, Eric Coleman wrote:
I've read, and reread the svn book on branch / merging... And I still don't understand what im supposed to do. I think I do this:
- SVN Copy trunk to the new branch
- checkout the branch, remove all files
- put new files into branch, commit, etc
- Delete files in trunk, merge branch to trunk
I somehow don't think that's right, but I honestly am not sure.
If you're really creating an entirely new branch with no files carried over, I would replace steps 1-2 with:
- SVN mkdir the new branch in branches/
- Commit that (nothing to clear or checkout).
- Continue as above...
But really, why not do this:
- Delete trunk.
- Move in new files.
- Commit.
I don't see a need for branches if you're just replacing the entire system. If you want to keep the old one around, create a tag or branch for it _before_ you do the steps above.
I think your scenario is rather rare, in svn supported projects.
-- Sune.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 2006-05-02 12:40:29 -0400, Eric Coleman wrote:
Thanks for the information.... The reason is that:
This is a commercial product. We need to maintain the current release while we finish work up on the next version. The next one is the biggest update we've done since launch, and well, just don't want to get caught with our pants down.
Isn't that what tags are for? you then work on a tag and merge any changes you need upstream to the trunk.
Dan
Ahh, Im not sure... I always mark a release with a tag, and everything stays in trunk, but this time we haven't nearly finished the next version, and it's going to take a couple weeks. We have snapshot builds from trunk and wanted to keep it stable and at the current version until we were ready to roll the next update.
Regards,
Eric Coleman
On May 2, 2006, at 12:43 PM, Dan Weeks wrote:
On 2006-05-02 12:40:29 -0400, Eric Coleman wrote:
Thanks for the information.... The reason is that:
This is a commercial product. We need to maintain the current release while we finish work up on the next version. The next one is the biggest update we've done since launch, and well, just don't want to get caught with our pants down.
Isn't that what tags are for? you then work on a tag and merge any changes you need upstream to the trunk.
Dan
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On May 2, 2006, at 12:43 PM, Dan Weeks wrote:
On 2006-05-02 12:40:29 -0400, Eric Coleman wrote:
Thanks for the information.... The reason is that:
This is a commercial product. We need to maintain the current release while we finish work up on the next version. The next one is the biggest update we've done since launch, and well, just don't want to get caught with our pants down.
Isn't that what tags are for? you then work on a tag and merge any changes you need upstream to the trunk.
That's what branches are for. A typical workflow for creating a major new version of a product might be:
1. tag the the last stable shipped sources from the trunk (svn cp $repo/trunk/ $repo/tags/1.0.1) 2. work on the unstable/development version commences on the trunk 3. maintenance work on the stable version can proceed on a branch from the old trunk snapshot (e.g. if you need to do bug fixes on stable version, create a branch: svn cp $repo/tags/1.0.1 $repo/ branches/1.0.x)
A variation on this is to perform the new development on a branch, and keep the trunk for maintenance on the stable version.
The question is how comprehensive the changes are; if there's really _no_ sharing and no history between the two versions, Eric probably wants to do what Sune said if he wants the new code to be the trunk:
But really, why not do this:
- Delete trunk.
- Move in new files.
- Commit.
It's the simplest option for the scenario where literally _everything_ is different, from the ground up. But it's not usually what you want to do, because it doesn't preserve the history of the files.
Chris
On 02/05/2006, at 19:24, Chris Thomas wrote:
The question is how comprehensive the changes are; if there's really _no_ sharing and no history between the two versions, Eric probably wants to do what Sune said if he wants the new code to be the trunk:
But really, why not do this:
- Delete trunk.
- Move in new files.
- Commit.
It's the simplest option for the scenario where literally _everything_ is different, from the ground up. But it's not usually what you want to do, because it doesn't preserve the history of the files.
Right... it's only for this rather special scenario. To the OP: I would add a step 0.5) Copy trunk to a tag or branch (in svn, there is no real difference; only what you read into it), to make sure you can still do patches to it etc.
-- Sune.
-
Aparajita Fishman -
Chris Thomas -
Dan Weeks -
Eric Coleman -
Luke Daley -
Sune Foldager