[SVN] Repository branches/libs experiments
I've set up a couple of my development branches in SVN. See the attached screenshot of the Boost.System branch. It wasn't entirely clear how to cope with the fact that typical boost libraries have several sections. For example, Boost.System has one header in boost-root/boost, other headers in boost-root/boost/system, and then the rest of the library in boost-root/libs/system. I've currently got the filesystem branch organized like this: /svn/boost/branches/libs/ system/ boost/ system/... system/ build/... doc/... src/... test/... That works, but I'm wondering if it would be more consistent to have organized it like this: /svn/boost/branches/libs/ system/ boost/ system/... libs/ system/ build/... doc/... src/... test/... In other words, organized the sub-tree under /svn/boost/branches/libs/system exactly the same way the trunk is organized. That might be easier for others to understand. I also wonder if it has any advantages as far as various SVN operations go. Opinions? --Beman
On 25/08/07, Beman Dawes <bdawes@acm.org> wrote:
*snip*
/svn/boost/branches/libs/ system/ boost/ system/... libs/ system/ build/... doc/... src/... test/...
In other words, organized the sub-tree under /svn/boost/branches/libs/system exactly the same way the trunk is organized. That might be easier for others to understand. I also wonder if it has any advantages as far as various SVN operations go.
Opinions?
Since SVN copy operations are so cheap, wouldn't it be simpler to have each branch as a complete copy of some stable tree, with some isolated work stuck in? That way, a naive user (such as myself) can just check out a branch - eg. the system branch - and have a complete boost tree that they can test, use or develop with. As it stands, the 'branch' appears to be a subset of boost, whereas I would have expected a complete 'fork' (albeit a temporary one). Regards, Darren
I would add that I was quite confused about this - and still don't feel comfortable with it. For what its worth here's what I did. I took SVN documentation at their word that copies are "cheap" and have no reason to doubt this. I created a branch of the last rlease and called it "serialization next release" so far so good. Then I made changes whereever I wanted. It turns out that the changes were in more than one directory so creating branches on various SVN directories would be a pain in the neck. so far so good Checked in my changes to the branch - smooth as silk. After a while using my changes on my own machine, merge to "trunk" to rain the benefits of my efforts upon your world. (This crashed the whole test system - which embarrassed me no end - not an easy thing to do - but I digress). The merging into the trunk was very confusing to me and I had to spend a lot of time getting things on my machine balled up and then unballed up. Here are a couple of things. First of all, i had hoped I could just "merge" the changes on my branch directly into the trunk. There may be a way to do this with the command line interface but the windows interface doesn't let you do it. Probably a good thing too. Now I realise that directly merging into the trunk could create conflicts which would otherwise go unnoticed. So it turns out the way to do this is a) switch one's directory/files you want to merge to the trunk branch. This step is not so obvious as it seems. When I did the switch, I switched the directory with the changes to trunk thinking that I would end up with exactly what I have but with the directory in question switched to the trunk. What I got was a whole directory tree from boost root under the directory I wanted to switch. It turns out that when you do the switch you have to switch to the corresponding tree/file in the trunk. Unballing this up took a while with alot of SVN errormessages etc. b) merge the changes from the branch (in this case "serialization next release" in to the directory/files which have been switched to the trunk. c) after testing, check the changes into the trunk. d) switch the directories/files back to your development branch. e) If you made any changes while in the trunk, you should merge those back into your development branch. There is probably an easier way to do this - maybe just having two trees on my system like i did with CVS. I'm still feeling my way around this thing. Robert Ramey Darren Garvey wrote:
On 25/08/07, Beman Dawes <bdawes@acm.org> wrote:
*snip*
/svn/boost/branches/libs/ system/ boost/ system/... libs/ system/ build/... doc/... src/... test/...
In other words, organized the sub-tree under /svn/boost/branches/libs/system exactly the same way the trunk is organized. That might be easier for others to understand. I also wonder if it has any advantages as far as various SVN operations go.
Opinions?
Since SVN copy operations are so cheap, wouldn't it be simpler to have each branch as a complete copy of some stable tree, with some isolated work stuck in? That way, a naive user (such as myself) can just check out a branch - eg. the system branch - and have a complete boost tree that they can test, use or develop with.
As it stands, the 'branch' appears to be a subset of boost, whereas I would have expected a complete 'fork' (albeit a temporary one).
Regards, Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Sat Aug 25 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
The merging into the trunk was very confusing to me and I had to spend a lot of time getting things on my machine balled up and then unballed up. Here are a couple of things.
First of all, i had hoped I could just "merge" the changes on my branch directly into the trunk. There may be a way to do this with the command line interface but the windows interface doesn't let you do it.
Subversion is a command-line tool, not a GUI. There is no "windows interface to Subversion." Somebody built a GUI that is an imperfect reflection of the underlying tool. Learn to use the command line; I mean this for everybody. I know some people love the GUIs, but first with CVS and now with SVN, I've repeatedly seen confusion or problems with those who are not familiar with, and unwilling to use, the command line. The built-in help is extremely good, and for those people who need more, the online book is written in terms of the command-line tool, not the GUIs, so how can you hope to learn the usage model if you only relate to the GUI? Once you understand the command line, it's easy to go back to a GUI and have a sense of what it's really doing. $ svn --help ... Available subcommands: ... list (ls) lock log merge ... $ svn --help merge merge: Apply the differences between two sources to a working copy path. usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH] 2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH] 3. merge [-c M | -r N:M] SOURCE[@REV] [WCPATH] ... <long exposition of details> -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
The built-in help is extremely good, and for those people who need more, the online book is written in terms of the command-line tool The built-in help is good, but reference-style. The book is good, but
David Abrahams wrote: particularly when it comes to merging, I found its explanations to be lacking. I needed several reads and quite a bit of experimentation to understand how merging works. Which is strange, because once you've understood it, it's really simple. So, there are two common usage scenarios for merging: bringing branch developments back into the trunk (or to another branch), and merging specific trunk changes to a branch. The merge command has three arguments: the old state, the new state, and the application state. In general, usage of merge is: 1) Old state is where the changes that you want to merge are not. 2) New state is where the changes are. 3) Application state is the place you want to merge to. The old and new states are represented by repository URLs, the application state is a working copy. Scenario 1: When development of a new feature on a branch is complete, you'll want the changes that you did to the branch on the trunk, too. The old state is therefore the branching point, the new state the final version of the branch, and the application state the current state of the trunk. Therefore: 1) Check out trunk, or update it to latest state. 2) svn merge .../branches/my-development-branch@branching-point .../branches/my-development-branch@HEAD . 3) Resolve conflicts, test, and check in trunk. Scenario 2: When you've made a release, you might want to port patches on the trunk to the release branch and create a point release. So you need to take changes on the trunk and apply them to the branch. The old state is the trunk before the checkins you want to catch, the new state is it afterwards, the application state is the branch. 1) Check out branch, or updated it to latest state. 2) svn merge .../trunk@rev-before-checkin .../trunk@rev-after-checkin . 3) Resolve conflicts, test, and check in branch. Be sure to mention the revisions you merged in the commit message, as SVN doesn't track such things in any way. E.g. "svn commit -m 'Merged r241 to r244 (bug #350935). This will become release 2.14.5'". One thing that is important to distinguish is release branches (the state of a major release, for bugfixing and point releases) and development branches (sandboxes for developing stuff). You can merge trunk changes over to release branches (and vice versa, if a bug is fixed on the release branch first), but you must never merge trunk changes to development branches! The changes from these merges would be picked up by the diffing of the branch's initial and final states. This means that the merging would try to apply changes to the trunk that were already made, hopelessly confusing the merger and making the merging very, very difficult. So don't do it. If you've spent so much time on a development that your patch is hopelessly out of date, you do this: create another branch based on the most recent trunk state, merge the changes of your original branch to this new one as you would merge them to the trunk, then fix everything that doesn't work. Then, merge the changes done on this new branch to the trunk. Maybe someone will find this little tutorial useful. Sebastian Redl
Sebastian Redl: ...
Maybe someone will find this little tutorial useful.
I for one did, thanks for that. But... what a pain! How do people manage to get work done at all? Isn't there a more streamlined way to do 1. Create branch 2. Work 3. Merge from trunk 4. Work 5. Merge from trunk 6. Test branch 7. Merge to trunk without remembering repository paths and revisions? I think that SVK can do this, but last I read about it, its Windows stability was being called into question.
Peter Dimov wrote:
I for one did, thanks for that. But... what a pain! How do people manage to get work done at all? Isn't there a more streamlined way to do
1. Create branch 2. Work 3. Merge from trunk 4. Work 5. Merge from trunk 6. Test branch 7. Merge to trunk
without remembering repository paths and revisions? I think that SVK can do this, but last I read about it, its Windows stability was being called into question.
I believe that the "streamlined" way is what I described in http://article.gmane.org/gmane.comp.lib.boost.devel/164321 . I suspect that if there are N svn users that are at least N+1 preferred ways of doing something. I find Sebastian's method (though correct for the general case) more complicated than is normally required. For projects where there is a small number of developers for a component (often one maintainer for a lib in boost), then checking out the trunk and simply switching the directories of interest to a working branch simplifies the merge from trunk operation... it is just an "snv update" command. Granted, if you are working on a set of sources at the same time as another developer, you will need to merge your branch with the trunk changes... but I find this to happen less often than the more general case and can still be performed with only switching work areas from the trunk checkout to a branch. And so to complete my previous post with the "trivial merge operation" commands (see post for details of steps 1-4): 1. Clean trunk checkout. 2. Copy directories within svn (branch) 3. Switch working directories. 4. Work, merge from trunk, work, merge from trunk.... 5. Complete work and merge back to trunk (completing use case from previous post) cd <working trunk directory>/boost/system svn switch https://svn.boost.org/svn/boost/trunk/boost/system <https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system> Updated to revision XX. <-- svn tells you the revision that you are now at svn merge https://svn.boost.org/svn/boost/trunk/boost/system@XX https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system@XX . cd ../../libs/system svn switch https://svn.boost.org/svn/boost/trunk/libs/system <https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system> Updated to revision YY. <-- svn tells you the revision that you are now at svn merge https://svn.boost.org/svn/boost/trunk/libs/system@YY https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system@YY . svn commit -m "committing changes from caisse system branch to trunk, fixing some problem." What I like about this method is I don't have to remember versions for the merge. More work is still required if somebody else has made changes to "system". In that case, the resulting merge will contain potentially unexpected results if I hadn't been paying attention. The merge will still take care of combining the changes, but it may have been later than I wanted and now I have some more work to do before the commit. I hope this is useful is some way. Please let me know if I'm missing the point. Best Regards - Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
2007/8/26, Peter Dimov <pdimov@pdimov.com>:
Sebastian Redl:
...
Maybe someone will find this little tutorial useful.
I for one did, thanks for that. But... what a pain! How do people manage to get work done at all? Isn't there a more streamlined way to do
1. Create branch 2. Work 3. Merge from trunk 4. Work 5. Merge from trunk 6. Test branch 7. Merge to trunk
without remembering repository paths and revisions? I think that SVK can do this, but last I read about it, its Windows stability was being called into question.
How about using svnmerge? http://www.orcaware.com/svn/wiki/Svnmerge.py (The same functionality is to be included in next svn release) /$
on Sun Aug 26 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Sebastian Redl:
...
Maybe someone will find this little tutorial useful.
I for one did, thanks for that. But... what a pain! How do people manage to get work done at all? Isn't there a more streamlined way to do
1. Create branch 2. Work 3. Merge from trunk 4. Work 5. Merge from trunk 6. Test branch 7. Merge to trunk
without remembering repository paths and revisions?
Yes: http://www.orcaware.com/svn/wiki/Svnmerge.py We just have to mandate that everyone use it. The next version of Subversion will make it unnecessary (http://blogs.open.collab.net/svn/2007/05/the_subversion__1.html) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Sun Aug 26 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Sebastian Redl:
...
Maybe someone will find this little tutorial useful. I for one did, thanks for that. But... what a pain! How do people manage to get work done at all? Isn't there a more streamlined way to do
1. Create branch 2. Work 3. Merge from trunk 4. Work 5. Merge from trunk 6. Test branch 7. Merge to trunk
without remembering repository paths and revisions?
Yes: http://www.orcaware.com/svn/wiki/Svnmerge.py
We just have to mandate that everyone use it.
If I use it on branches where I'm the maintainer, does svnmerge.py work OK for those branches even if others are not using it for other branches? Or do all Boost developers have to do all merges via svnmerge.py. On my branches, should the rule-of-thumb be "never use the raw SVN merge command or GUI equivalents; always use svnmerge.py"?
The next version of Subversion will make it unnecessary (http://blogs.open.collab.net/svn/2007/05/the_subversion__1.html)
It sounds as if we need a Wiki page describing Boost's preferred (and in some cases mandated) SVN procedures. Any volunteers to write and maintain such a page? --Beman
Beman Dawes wrote:
It sounds as if we need a Wiki page describing Boost's preferred (and in some cases mandated) SVN procedures.
Any volunteers to write and maintain such a page?
--Beman
It seems like my own preferences for svn procedures might be a little different than other people's; however, I would be happy to take what I think are the recommendations in this thread and create a wiki page for review. There maybe somebody with development experience within boost that might be better suited but if that person doesn't materialize I am happy to help wherever it makes sense. Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
on Mon Aug 27 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Yes: http://www.orcaware.com/svn/wiki/Svnmerge.py
We just have to mandate that everyone use it.
If I use it on branches where I'm the maintainer, does svnmerge.py work OK for those branches even if others are not using it for other branches? Or do all Boost developers have to do all merges via svnmerge.py.
I don't know.
On my branches, should the rule-of-thumb be "never use the raw SVN merge command or GUI equivalents; always use svnmerge.py"?
Yeah.
The next version of Subversion will make it unnecessary (http://blogs.open.collab.net/svn/2007/05/the_subversion__1.html)
It sounds as if we need a Wiki page describing Boost's preferred (and in some cases mandated) SVN procedures.
Any volunteers to write and maintain such a page?
<ducks>...a bit swamped at the moment...</ducks> -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Sat Aug 25 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
The merging into the trunk was very confusing to me and I had to spend a lot of time getting things on my machine balled up and then unballed up. Here are a couple of things.
First of all, i had hoped I could just "merge" the changes on my branch directly into the trunk. There may be a way to do this with the command line interface but the windows interface doesn't let you do it.
Subversion is a command-line tool, not a GUI. There is no "windows interface to Subversion." Somebody built a GUI that is an imperfect reflection of the underlying tool.
That is less than accurate for Subversion. All the Subversion GUIs and CLIs, AFAIK, use the same Subversion library. So in a sense they are all UIs to the same tool. And hence the "svn" command is just as much an "imperfect reflection of the underlying tool" as TortoiseSVN. And in the case of TSVN I would say it's a much better reflection than "svn". It makes doing remote operations on the repo possible that I have yet to find a way to do with "svn".
Once you understand the command line, it's easy to go back to a GUI and have a sense of what it's really doing.
I found it harder to understand what Subversion is really doing from all the reading of the book, docs, etc. I found it much easier to understand just by using the TSVN repo browser.
$ svn --help merge
In the TSVN context menu "ToroiseSVN/Merge...", brings up a dialog with all the options with much better explanations then "svn --help". And with immediate access to the repo browser in various places. And with the ability to do diffs directly in the dialog (which integrates with WinMerge if you want). And with the ability to pick merge revision directly from the log, which means one doesn't have to remember the revision numbers which is the number one annoyance (and source of mistakes) for doing "svn merge". Please don't make the mistake of prejudging the available SVN GUI tools based on your bad experiences with CVS GUI tools. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Sun Aug 26 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Sat Aug 25 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
The merging into the trunk was very confusing to me and I had to spend a lot of time getting things on my machine balled up and then unballed up. Here are a couple of things.
First of all, i had hoped I could just "merge" the changes on my branch directly into the trunk. There may be a way to do this with the command line interface but the windows interface doesn't let you do it.
Subversion is a command-line tool, not a GUI. There is no "windows interface to Subversion." Somebody built a GUI that is an imperfect reflection of the underlying tool.
That is less than accurate for Subversion. All the Subversion GUIs and CLIs, AFAIK, use the same Subversion library.
Yes.
So in a sense they are all UIs to the same tool.
Yes. And there's no windows-specific interface to Subversion, other than those produced by parties other than the Subversion developers. That's all I menat.
And hence the "svn" command is just as much an "imperfect reflection of the underlying tool" as TortoiseSVN.
Except that it's the reference UI, and it's produced by the subversion developers.
Once you understand the command line, it's easy to go back to a GUI and have a sense of what it's really doing.
I found it harder to understand what Subversion is really doing from all the reading of the book, docs, etc. I found it much easier to understand just by using the TSVN repo browser.
$ svn --help merge
In the TSVN context menu "ToroiseSVN/Merge...", brings up a dialog with all the options with much better explanations then "svn --help". And with immediate access to the repo browser in various places. And with the ability to do diffs directly in the dialog (which integrates with WinMerge if you want). And with the ability to pick merge revision directly from the log, which means one doesn't have to remember the revision numbers which is the number one annoyance (and source of mistakes) for doing "svn merge".
Nobody should have to look at the log either. We should be using svnmerge.py
Please don't make the mistake of prejudging the available SVN GUI tools based on your bad experiences with CVS GUI tools.
I never had a bad experience with them. I use SVN and CVS "GUI" tools from within emacs; they're very useful. In fact, I love them. That said, I have a decent grounding in how the tools work because I read the official documentation and familiarized myself with the interfaces it describes. I want other Boost developers to have the same grounding, for their own sakes, and for mine (so the repo doesn't get messed up). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
on Sat Aug 25 2007, "Darren Garvey" <lists.drrngrvy-AT-googlemail.com> wrote:
On 25/08/07, Beman Dawes <bdawes@acm.org> wrote:
*snip*
/svn/boost/branches/libs/ system/ boost/ system/... libs/ system/ build/... doc/... src/... test/...
In other words, organized the sub-tree under /svn/boost/branches/libs/system exactly the same way the trunk is organized. That might be easier for others to understand. I also wonder if it has any advantages as far as various SVN operations go.
Opinions?
Since SVN copy operations are so cheap, wouldn't it be simpler to have each branch as a complete copy of some stable tree, with some isolated work stuck in? That way, a naive user (such as myself) can just check out a branch - eg. the system branch - and have a complete boost tree that they can test, use or develop with.
As it stands, the 'branch' appears to be a subset of boost, whereas I would have expected a complete 'fork' (albeit a temporary one).
Yeah, a complete fork is what I would expect, and probably want. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Sat Aug 25 2007, "Darren Garvey" <lists.drrngrvy-AT-googlemail.com> wrote:
On 25/08/07, Beman Dawes <bdawes@acm.org> wrote:
*snip*
/svn/boost/branches/libs/ system/ boost/ system/... libs/ system/ build/... doc/... src/... test/...
In other words, organized the sub-tree under /svn/boost/branches/libs/system exactly the same way the trunk is organized. That might be easier for others to understand. I also wonder if it has any advantages as far as various SVN operations go.
Opinions?
Since SVN copy operations are so cheap, wouldn't it be simpler to have each branch as a complete copy of some stable tree, with some isolated work stuck in? That way, a naive user (such as myself) can just check out a branch - eg. the system branch - and have a complete boost tree that they can test, use or develop with.
As it stands, the 'branch' appears to be a subset of boost, whereas I would have expected a complete 'fork' (albeit a temporary one).
Yeah, a complete fork is what I would expect, and probably want.
That's OK with me, but SVN copy will have to be not just cheap, but *very* cheap or disk usage will explode. --Beman
On 27/08/07, Beman Dawes <bdawes@acm.org> wrote:
David Abrahams wrote:
on Sat Aug 25 2007, "Darren Garvey" <lists.drrngrvy-AT-googlemail.com> wrote:
As it stands, the 'branch' appears to be a subset of boost, whereas I would have expected a complete 'fork' (albeit a temporary one).
Yeah, a complete fork is what I would expect, and probably want.
That's OK with me, but SVN copy will have to be not just cheap, but *very* cheap or disk usage will explode.
From 'the SVN book' (http://tinyurl.com/28yoyz):
"The main point here is that copies are cheap, both in time and space. Make branches as often as you want." IIUC, the copy is little more than a symlink (and probably a few table entries). Regards, Darren
Beman Dawes wrote:
I've set up a couple of my development branches in SVN. See the attached screenshot of the Boost.System branch.
It wasn't entirely clear how to cope with the fact that typical boost libraries have several sections. For example, Boost.System has one header in boost-root/boost, other headers in boost-root/boost/system, and then the rest of the library in boost-root/libs/system.
I've currently got the filesystem branch organized like this: <snip>
In other words, organized the sub-tree under /svn/boost/branches/libs/system exactly the same way the trunk is organized. That might be easier for others to understand. I also wonder if it has any advantages as far as various SVN operations go.
Opinions?
--Beman Let me start with, I'm no librarian and most of my knowledge comes from http://svnbook.red-bean.com/ and a lot of trial under various sized projects, some of which have many libraries, frameworks and components scattered all around.
Branches are a nice place to do work within the *system*. You can have history with your changes, collaborate and have that fuzzy feeling inside that when your drive crashes that your work is still somewhere. The high level branch directory structure is important for guiding developers where to place and find work, but the lower level structure is not very important. In other words, I think the layout (.../branches/libs/serialization) has been defined at the appropriate level. I would not provide structure beyond there. Perhaps some use case examples would be helpful. For instance: If I am making changes to "system" based on .../svn/boost/trunk I would do the following ( note: the Improving Practices document has users start with the stable .../boost/branch/release location but if your merge destination is the trunk and a dependency (prerequisite) is modified in the trunk, you will need to work that out in the trunk before changes are moved to the release branch. I'm still thinking this out. ) 1. Start with a clean check out of trunk. This is the basis for my changes and therefore it is what I need to make sure is "up-to-date" with other possible developer changes at various check points. Since it is my responsibility to merge back to the trunk and have stability, I will want to make sure that I'm keeping up with changes to the trunk. Notice, I did not copy the whole boost trunk to a branch because that just makes things more difficult when staying in sync with the trunk. A svn copy is inexpensive; however, it should not be confused with a symbolic link. Changes made to the trunk after the branch copy would have to be merged from the trunk into your branch. Yuck. svn co https://svn.boost.org/svn/boost/trunk 2. Copy within svn the directories (or files) I want to modify to a branch. For my example it might look like this: svn mkdir https://svn.boost.org/svn/boost/branches/libs/system/caisse -m "Making a branch director for my system work" svn cp https://svn.boost.org/svn/boost/trunk/boost/system https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system -m "copy boost/system into working branch" svn cp https://svn.boost.org/svn/boost/trunk/libs/system https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system -m "copy libs/system into working branch" Notice that I copied into a unique directory within branch/libs/system. This would allow others to make changes to system while using the .../boost/branches/libs/system location also. As you can see I don't really care that the structure doesn't look the same as the standard boost directory layout. The switch will handle that problem. 3. Switch your working areas of the trunk checkout to the branch copy you just made. Subversion operations will then be on the branch location for the switched directories (files) and the trunk for everything else. cd <your new checkout of the boost trunk> cd boost/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system cd ../../libs/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system 4. Work as normal. I'm version control happy and believe numbers are free so I like to check in often. Sometimes I just checkpoint changes that don't even compile. I figure it is my branch and the tool is there to help me. Occasionally I will check for changes on the trunk that I can "svn update" to make sure I'm in sync with the trunk. 5. Eventually I'm done developing and everything works great. I then "svn update" to ensure there are no more trunk changes. At this point I know that I'm in sync with the trunk so doing a merge into the trunk is a simple operation. I apologize if this was just common knowledge noise and I've wasted both your time and bandwidth. I don't have access to boost svn (write) so I wasn't able to try this out. There may be issues with the https access that I haven't taken into account. The steps are what I follow daily, the commands may be off. Your mileage may vary. Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Hi! Michael Caisse schrieb:
cd <your new checkout of the boost trunk> cd boost/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system cd ../../libs/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system
This way you won't keep track of which revision of the trunk you used for developing your branch. I figured that one out when thinking about the requirement to have places in your repository (trunk or branches or tags) which can just be checked out, compiled, and which "just work". This includes the state of other libraries, too: 1. copy part of trunk to branch 2. use mixed trunk and branch working dir for development 3. regularly update your trunk workdir 4. screw things up on the branch (by developing some feature) 5. try going back to a consistent state: 5a. update your branch to a previous state 5b. update your trunk to a previous state ..... which previous states of your branch and the trunk will work? Which ones did you use? Did you create a mixed trunk/branch tag for this purpose? So why not directly work on a full copy instead of mixing trunk and branch? So I will prefer "full" branches: svn copy .../trunk .../branches/whatever Frank
Frank Birbacher wrote:
Hi!
Michael Caisse schrieb:
cd <your new checkout of the boost trunk> cd boost/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/boost_system cd ../../libs/system svn switch https://svn.boost.org/svn/boost/branches/libs/system/caisse/libs_system
This way you won't keep track of which revision of the trunk you used for developing your branch. I figured that one out when thinking about
That is correct. I have done it both ways. I am making the following assumptions: 1. You will need to merge your changes back to the trunk 2. You are responsible for making sure the trunk works after your merge 3. Changes to the trunk that happen before your merge are your problem (as in a dependency change). 4. You are the only one making changes to a particular library. I believe #1, #2 and #3 are consistent with the Improving Practices wiki page. #4 is a simplification; however, it seems to be how boost libraries are maintained. Creating a "full" branch copy (svn copy .../trunk .../branches/whatever) is more useful if you expect changes to be occurring in the same areas your are working. It is also useful if you expect lots of changes to be occurring to dependencies and you want to hand pick modifications for a merge into your branch. <snip>
which previous states of your branch and the trunk will work?
I typically don't care.... in-as-much that I have to merge with the existing trunk and that result needs to work. I follow this procedure: 1. make changes to code 2. have a checkpoint that does something (not unnecessarily complete) 3. "svn update" so that I'm current with the trunk (noting the dependencies that might have changed) 4. verify that my checkpoint still behaves properly 5. repeat starting at 1 until my changes are complete
Which ones did you use? Did you create a mixed trunk/branch tag for this purpose? So why not directly work on a full copy instead of mixing trunk and branch?
I create a mix because keeping track of which changeset I branched at, which changeset I merged last and what is the mixture I have going is just too much to worry about in most cases. I get more done by not worrying about it and keeping everything else in sync with the trunk through the simple "svn update" command. At the end of the day my changes have to work with the trunk anyhow, and I don't have to worry about svn merge path@what_was_that_version being wrong and causing more work for myself because I used the wrong changeset. If things are more complicated (lots of maintainers on one lib working at the same time), which I don't think happens in boost from what I can tell, then full branches with the extra bookkeeping often becomes a necessity. Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
participants (10)
-
Beman Dawes -
Darren Garvey -
David Abrahams -
Frank Birbacher -
Henrik Sundberg -
Michael Caisse -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Sebastian Redl