Steps before moving to Subversion
Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week. (I've been using Subversion on my machine for about a month, and quickly became convinced it is superior to CVS.) Points discussed included the importance of a slow, step-by-step approach, because of the importance to Boost and to individual developers, and the need to build familiarity before diving in head first. Doug Gregor will lead the effort, and will be the contact at IU when issues arise. Hopefully Troy Straszheim can help, given that he has already setup a Boost SVN repository. Some of the possible tasks to be accomplished before a final conversion: * Research any remaining questions from Boosters regarding Subversion. * Decide on the repository directory structure - follow Troy's lead or maybe something else? (One of the advantages of Subversion is that the repository directory structure isn't hard-wired, but that means we have to decide which approach is best.) * Set up a trial repository, like the one Troy set up, but on the actual machine at IU. * Set up write authorization. This might be a good time to prune the write-access list to those still active. * Load test. (Maybe set a time, and have a bunch of Boosters hit the repository at the same time?) * Make final go/no-go decision. This probably involves both discussion on the list and polling the moderators (as the closest thing we have to a steering committee.) * Put change notifications in place. * Verify that backup (tarball or whatever) procedures are in place and functioning. * Update Boost documentation which refers to the source repository. * Schedule and execute the actual changeover. Comments? --Beman PS: The book "Version Control with Subversion" by Collins-Sussman, Fitzpatrick, and Pilato, is worthwhile, either in hard copy (O'Reilly) or download from http://svnbook.red-bean.com/
Beman Dawes wrote:
Comments?
* Update the wiki with a set of concerns about moving to SVN. My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-( Note.. SourceForge is starting development and testing to offer SVN service. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
From the newsgroup postings, this is the one that typically bites people who are switching from CVS. Many people have scripts that do things like 'fetch
We just switched to Subversion from SourceSafe (no snickering please) at our company. It's basically been a good experience, but with the following areas of SVN caused problems: 1) svn:externals. 2) the --non-recursive flag on 'svn update' and 'svn checkout'. 3) berkley-DB repository speed. 1) svn:externals. We used svn:externals to replace SourceSafe's concept of "shared files". However, svn:externals are bad because - commits at the top of a tree that contains externals do not propogate through the externals. So, if you have a large tree, some parts that are externals and some that are not, and you've made changes all over, when you commit you have to remember to visit every single external and then commit there as well. - branching and tagging doesn't do anything special with svn:externals, and you'd want it to. 2) the --non-recursive flag on 'svn update' and 'svn checkout'. the top level, look at it, and then decide what other parts to fetch'. For example, you might fetch the top level of your tree to get a configuration file that tells you what to do next. However, once you've fetched something non-recursively, you can't then change your mind and fetch the rest of the tree recursively. Actually, the problem is much worse than a missing flag on a command line, the --non-recursive flag is completely broken and results in what is essentially a corrupt work area. If you look around at the Subversion postings, there is a bug report against this called ["svn checkout -N" should actually work] http://subversion.tigris.org/issues/show_bug.cgi?id=695 3) berkley-DB repository speed. It's slow to do common operations like fetching new files and getting history. You might want to consider using the new native file format FSFS, as it is faster. We also used TortoiseSVN to replace the SourceSafe explorer. It's very slow, and I've basically stopped using it except for the merge dialog. I can't comment on the dysfunctional merge issue - I've used the merge feature, and I've not lost any work with it yet. Hope this helps. Rob. "Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:4268132D.5050203@redshift-software.com...
Beman Dawes wrote:
Comments?
* Update the wiki with a set of concerns about moving to SVN.
My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-(
Note.. SourceForge is starting development and testing to offer SVN service.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Mathews wrote:
1) svn:externals. We used svn:externals to replace SourceSafe's concept of "shared files". However, svn:externals are bad because - commits at the top of a tree that contains externals do not propogate through the externals. So, if you have a large tree, some parts that are externals and some that are not, and you've made changes all over, when you commit you have to remember to visit every single external and then commit there as well. - branching and tagging doesn't do anything special with svn:externals, and you'd want it to.
We use svn:externals for the same reason and I understand the problems too. From the svn bug reports it looks like they are working on 'relative' externals which will then be known to be in the same repository and can therefore be commited in one go. This will also bring in extra flags for externals to say whether to copy the external on a branch/tag or to mark it for the current revision etc. This should address what you need (and we) need, but I've no idea when this functionality will be completed. Might be worth searching their mailing list/bug reports for more info.
3) berkley-DB repository speed. It's slow to do common operations like fetching new files and getting history. You might want to consider using the new native file format FSFS, as it is faster.
FSFS is faster for a lot of things, but not for a checkout of HEAD. Read the docs as they explain that the FSFS repo format stores diffs from the previous revision so to build up the HEAD revision, it has to go back to the start the slowly build up the changes. We changed our repo from a BDB to an FSFS with 1.1.4 when a few more issues seemed to have been cleared up, mainly because it allows us to use rsync to back it up to another server as each revision is just a file, rather than having to do a hotcopy of the entire db file. FSFS is quicker for other operations, and are much smaller in our experience.
We also used TortoiseSVN to replace the SourceSafe explorer. It's very slow, and I've basically stopped using it except for the merge dialog.
Turn of 'recurse into folders to fetch status' in the 'look and feel' tab of TSVN options. That will dramatically increase its speed. I've come from VSS too, and there isn't a single feature of VSS that I miss now I've been using subversion and TSVN for over a year.
I can't comment on the dysfunctional merge issue - I've used the merge feature, and I've not lost any work with it yet.
I use merge and have had no issues with it. Cheers Russell
"Russell Hind" <rh_gmane@mac.com> wrote in message news:d4a78b$dfm$1@sea.gmane.org...
Robert Mathews wrote:
1) svn:externals. We used svn:externals to replace SourceSafe's concept of "shared files". However, svn:externals are bad because - commits at the top of a tree that contains externals do not propogate through the externals. So, if you have a large tree, some parts that are externals and some that are not, and you've made changes all over, when
you
commit you have to remember to visit every single external and then commit there as well. - branching and tagging doesn't do anything special with svn:externals, and you'd want it to.
We use svn:externals for the same reason and I understand the problems too. From the svn bug reports it looks like they are working on 'relative' externals which will then be known to be in the same repository and can therefore be commited in one go.
Right - that's another problem (for now) with them that I forgot to mention - all svn:externals are absolute pathnames, so that you have to hard code in the name of the server where the externals are. This means that if you were to rename your server, all of the svn:externals would be broken.
This will also bring in extra flags for externals to say whether to copy the external on a branch/tag or to mark it for the current revision etc.
That'll be nice.
This should address what you need (and we) need, but I've no idea when this functionality will be completed. Might be worth searching their mailing list/bug reports for more info.
3) berkley-DB repository speed. It's slow to do common operations like fetching new files and getting history. You might want to consider using the new native file format
FSFS,
as it is faster.
FSFS is faster for a lot of things, but not for a checkout of HEAD. Read the docs as they explain that the FSFS repo format stores diffs from the previous revision so to build up the HEAD revision, it has to go back to the start the slowly build up the changes.
We changed our repo from a BDB to an FSFS with 1.1.4 when a few more issues seemed to have been cleared up, mainly because it allows us to use rsync to back it up to another server as each revision is just a file, rather than having to do a hotcopy of the entire db file. FSFS is quicker for other operations, and are much smaller in our experience.
We also used TortoiseSVN to replace the SourceSafe explorer. It's very
slow,
and I've basically stopped using it except for the merge dialog.
Turn of 'recurse into folders to fetch status' in the 'look and feel' tab of TSVN options. That will dramatically increase its speed.
Sure, then it's dramatically faster, but also doesn't tell you if a folder contains a subfolder that has changes that need committing .. couple that feature with the need to visit each externals folder individually when doing commits, and you've got a situation where you're likely forget to check some code in.
I've come from VSS too, and there isn't a single feature of VSS that I miss now I've been using subversion and TSVN for over a year.
No, no, please don't get the idea that I was *missing* VSS for a single moment. Only that when the folks at boost design their repository, they'll want to minimize the number of externals they use, and that they'll want to watch out for the '--non-recursive' flag.
I can't comment on the dysfunctional merge issue - I've used the merge feature, and I've not lost any work with it yet.
I use merge and have had no issues with it.
Cheers
Russell
_______________________________________________ Unsubscribe & other changes:
On the right hand side of http://www.cvsnt.com/cvspro/svn.htm there purports to be a comparison of svn and cvsnt is it badly out of date? can we afford to NOT have the features lists as yes for cvsnt and no for svn? I'm reading the svn book (O'Reilly) online and coupled with some comments here I have reservations about using svn. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
On the right hand side of http://www.cvsnt.com/cvspro/svn.htm there purports to be a comparison of svn and cvsnt is it badly out of date?
The problem with every comparison is that unless you specify *exactly* what's compared, it's hard to make any decision. Speaking of the page you've referenced: Efficient storage of binary files using binary deltas CVSNT: YES SVN: NO This is plain wrong, Subversion uses binary deltas for all files since day one. optional locking (reserved checkouts). CVSNT: YES SVN: NO This feature will be in svn 1.2 repository-level ACLs CVSNT: YES CVSNT: NO I don't know what they mean. In svn 1.0 I can restrict access for any substree to any set of users. Set enforced protocols allow server to lock out clients connecting over insecure protocols or using insecure/inefficient options. Easily remove protocols (without recompile) More sophisticated / extra triggers available e.g. postcommit. Triggers also available via COM/DLL/.so interfaces UTF-8 (Unicode) Server. Those features are so obsure that I can't comment at all. Multi Lingual filenames suport. CVSNT: YES SVN: NO False. SVN holds all filesnames in UTF-8 internally and has no problems with russian file names. So, it looks like the comparison page is either out-of-date, or incorrect. - Volodya
On 4/26/05, Vladimir Prus <ghost@cs.msu.su> wrote:
So, it looks like the comparison page is either out-of-date, or incorrect.
I agree. My original point about CVSNT was that it supports "Merge Points", which makes doing multiple merges between branches a lot less painful than it is with CVS or even SVN. I did some testing of CVSNT a week or so ago, and this is indeed a nice feature, but I did encounter some instabilities in the tool. The rename support seems especially buggy and even warns you when you use it: "cvsnt rename: Warning: rename is still experimental and may not behave as you would expect" I was even able to get the client to dump core; not very confidence-inducing. If you have a Windows-heavy user base and a legacy CVS environment, CVSNT may be the right tool. However I don't think all of the added authentication and other functionality is pertinent for Boost, especially if the server-side will be running on a UNIX box. I believe SVN has all of the features that make it a CVS killer. The branch/merge semantics are a lot less cumbersome than with CVS, particularly when you take into account all of the tagging required to make CVS branch/merge manageable. When combined with a little bit of procedure (e.g. noting where merges happen in your commit comments), the lack of a history-sensitive merge is hardly a showstopper. Presumably a future release of SVN will include this feature (it is a medium-term goal on their roadmap) and then you won't even need to worry about those merge-point comments. I say full-speed ahead into SVN-land! -- Caleb Epstein caleb dot epstein at gmail dot com
"Rene Rivera" <grafik.list@redshift-software.com> escribió en el mensaje news:4268132D.5050203@redshift-software.com...
Beman Dawes wrote:
Comments?
* Update the wiki with a set of concerns about moving to SVN.
My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-(
FWIW we've been using SVN for a year and a half now and we've never had a merge problem. Fernando Cacciola
Fernando Cacciola wrote:
"Rene Rivera" <grafik.list@redshift-software.com> escribi� en el mensaje news:4268132D.5050203@redshift-software.com...
Beman Dawes wrote:
Comments?
* Update the wiki with a set of concerns about moving to SVN.
My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-(
FWIW we've been using SVN for a year and a half now and we've never had a merge problem.
That's good to hear. Since I've only used SVN on that job I'd suspect my problems could be related to the way the repository was used, or misused as the case may be. Although there is a documented deficiency with SVN not using the branch and revision history to do the merge. It's one of those things we should watch out for. Not one of those that would prevent us from moving to SVN ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On 4/21/05, Rene Rivera <grafik.list@redshift-software.com> wrote:
Fernando Cacciola wrote:
FWIW we've been using SVN for a year and a half now and we've never had a merge problem.
That's good to hear. Since I've only used SVN on that job I'd suspect my problems could be related to the way the repository was used, or misused as the case may be. Although there is a documented deficiency with SVN not using the branch and revision history to do the merge.
But CVS is just as bad if not worse in this regard, unless you lay down tags everywhere. Or if you use CVSNT, which is the only open-source tool I've encountered that supports history sensitive merging. As large projects are finding out (gcc, Mono), having tons of branches and tags slows down CVS a great deal after a while. Merging is not history sensitive in SVN nor is it in CVS, so you must follow best practices to be able to merge to/from a branch more than once successfully. In CVS this means tagging like a maniac, and in SVN its a simple matter of leaving an explicit comment about your merge point when you do merge code. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein <caleb.epstein@gmail.com> writes:
But CVS is just as bad if not worse in this regard, unless you lay down tags everywhere. Or if you use CVSNT, which is the only open-source tool I've encountered that supports history sensitive merging.
As large projects are finding out (gcc, Mono), having tons of branches and tags slows down CVS a great deal after a while. Merging is not history sensitive in SVN nor is it in CVS, so you must follow best practices to be able to merge to/from a branch more than once successfully. In CVS this means tagging like a maniac, and in SVN its a simple matter of leaving an explicit comment about your merge point when you do merge code.
Or you can use svnmerge. If it works as advertised, I'd like to have a project policy that we do so. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Rene Rivera <grafik.list@redshift-software.com> writes:
Beman Dawes wrote:
Comments?
* Update the wiki with a set of concerns about moving to SVN.
My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-(
Do you use svnmerge? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-(
Do you use svnmerge?
No. I used "svn merge -r N:M -m "Something" somefile.php". Which is what the svnbook says to use. It happened to generate a conflict because of changes in the trunk (I was working on a branch). The conflict file it generated lost a line. And I did not notice because I did not look at the non-conflict files. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
My biggest concern is still the disfunctional merge operation of SVN. In my last contract job a few weeks ago I had it loose a set of changes during a merge :-( Do you use svnmerge?
No. I used "svn merge -r N:M -m "Something" somefile.php". Which is what the svnbook says to use. It happened to generate a conflict because of changes in the trunk (I was working on a branch). The conflict file it generated lost a line. And I did not notice because I did not look at the non-conflict files.
There's a script called svnmerge that handles this, if you just agree to use that instead of svn's built-in merging. Please see http://lists.boost.org/boost/2005/02/19955.php -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
Do you use svnmerge?
No. I used "svn merge -r N:M -m "Something" somefile.php". Which is what the svnbook says to use. It happened to generate a conflict because of changes in the trunk (I was working on a branch). The conflict file it generated lost a line. And I did not notice because I did not look at the non-conflict files.
There's a script called svnmerge that handles this, if you just agree to use that instead of svn's built-in merging. Please see http://lists.boost.org/boost/2005/02/19955.php
Didn't know about the script, like I said first it was likely the procedures of the client that got me in trouble. In fact the client knows much less about version control and software development than me in this case. But since it was the first time I used svn I was bound to get into trouble ;-) I think the *big* point to this is that.. If there are pitfalls, we'd better make sure we know about them. And if there are "correct" procedures to follow we need to know about them and follow them. And if there are "incorrect" procedures to at best make them impossible to use them. But since you mention the svnmerge script, here's some questions.. Is there a way to use that script from one of the svn GUI clients? Is there a way to prevent the use of "svn merge"? Basically, what's to prevent users, other than convention, from messing up? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
But since you mention the svnmerge script, here's some questions.. Is there a way to use that script from one of the svn GUI clients? Is there a way to prevent the use of "svn merge"? Basically, what's to prevent users, other than convention, from messing up?
Never mind.. just found the documentation of svnmerge. And hence have some answers. But here's the thing, it solves the book keeping aspect of the svn merge. But it doesn't solve the problem I had. It's not like I did not follow the procedure of marking the comments with merge points and using "-r N:M" to only merge the un-merged changes. My problem was that the svn merge operation lost a line, literally. Which means that the conflict resolution algorithm has a problem. So unless there's a solution out there that doesn't use "svn merge" we might get bitten. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
Rene Rivera wrote:
But since you mention the svnmerge script, here's some questions.. Is there a way to use that script from one of the svn GUI clients? Is there a way to prevent the use of "svn merge"? Basically, what's to prevent users, other than convention, from messing up?
Never mind.. just found the documentation of svnmerge. And hence have some answers.
What are they, please? I don't know them.
But here's the thing, it solves the book keeping aspect of the svn merge. But it doesn't solve the problem I had. It's not like I did not follow the procedure of marking the comments with merge points and using "-r N:M" to only merge the un-merged changes. My problem was that the svn merge operation lost a line, literally. Which means that the conflict resolution algorithm has a problem. So unless there's a solution out there that doesn't use "svn merge" we might get bitten.
Oh. Well it's not nice to have a bug, but you have to check your merge results by hand anyway, don't you? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Never mind.. just found the documentation of svnmerge. And hence have some answers.
What are they, please? I don't know them.
http://www.dellroad.org/svnmerge/index
But here's the thing, it solves the book keeping aspect of the svn merge. But it doesn't solve the problem I had. It's not like I did not follow the procedure of marking the comments with merge points and using "-r N:M" to only merge the un-merged changes. My problem was that the svn merge operation lost a line, literally. Which means that the conflict resolution algorithm has a problem. So unless there's a solution out there that doesn't use "svn merge" we might get bitten.
Oh. Well it's not nice to have a bug, but you have to check your merge results by hand anyway, don't you?
Of course you should check the merge results.. And I did in this case. But what I did was open the source file, which has the usual "<<<" and ">>>" conflict markers, and edit to make sure all the changes where in there. But that conflict result was missing a line. When I did a diff from what I had to the repository version on my branch, the other check I go through when merging, the missing line obviously didn't show either. What I failed to do was do a manual diff between the two other original source files, the head revision and the branch revision, which svn creates when it finds a conflict. I don't consider what I did as unusual, as I was expecting the conflict resolution of a merge to *never* loose information, under any circumstances. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Never mind.. just found the documentation of svnmerge. And hence have some answers. What are they, please? I don't know them.
I don't see any answers to:
Is there a way to use that script from one of the svn GUI clients? Is there a way to prevent the use of "svn merge"? Basically, what's to prevent users, other than convention, from messing up?
Am I missing something?
But here's the thing, it solves the book keeping aspect of the svn merge. But it doesn't solve the problem I had. It's not like I did not follow the procedure of marking the comments with merge points and using "-r N:M" to only merge the un-merged changes. My problem was that the svn merge operation lost a line, literally. Which means that the conflict resolution algorithm has a problem. So unless there's a solution out there that doesn't use "svn merge" we might get bitten. Oh. Well it's not nice to have a bug, but you have to check your merge results by hand anyway, don't you?
Of course you should check the merge results.. And I did in this case. But what I did was open the source file, which has the usual "<<<" and ">>>" conflict markers, and edit to make sure all the changes where in there. But that conflict result was missing a line. When I did a diff from what I had to the repository version on my branch, the other check I go through when merging, the missing line obviously didn't show either. What I failed to do was do a manual diff between the two other original source files, the head revision and the branch revision, which svn creates when it finds a conflict. I don't consider what I did as unusual, as I was expecting the conflict resolution of a merge to *never* loose information, under any circumstances.
Well, that's really embarrassing. How hard can it be to get that right? A fix must be on its way... no? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Never mind.. just found the documentation of svnmerge. And hence have some answers.
What are they, please? I don't know them.
I don't see any answers to:
Is there a way to use that script from one of the svn GUI clients?
Since it's a 'sh' script I would think the answer is no. But we would have to check with each individual GUI client to find out.
Is there a way to prevent the use of "svn merge"? Basically, what's to prevent users, other than convention, from messing up?
Since it written on top of "svn merge" it can't really prevent the use of "svn merge". It only augments it. Ideally someone needs to write an svn client that totally replaces the "svn merge" by doing all the diffs and merge itself.
svn creates when it finds a conflict. I don't consider what I did as unusual, as I was expecting the conflict resolution of a merge to *never* loose information, under any circumstances.
Well, that's really embarrassing.
Particularly embarrassing for me, as I'm very careful with version control usage. And it's why I have a persistent memory of the incident.
How hard can it be to get that right? A fix must be on its way... no?
I would really hope so.. But given that working on merge issues seems to be a low priority for them.. I would not be so sure. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20050421155249.032c8230@mailhost.esva.net...
Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week.
...
Ten minutes after sending the above I remembered the suggestion that we move the sandbox to Subversion first. That seems like a good way to get our feet wet. Comments? --Beman
At Thursday 2005-04-21 14:02, you wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20050421155249.032c8230@mailhost.esva.net...
Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week.
...
Ten minutes after sending the above I remembered the suggestion that we move the sandbox to Subversion first. That seems like a good way to get our feet wet.
Comments?
that's a plan I could easily support. BTW, it would be "nice" when we're all set up if we could make "regular boost" a part of the sandbox...so we could get everything with one update... or some mechanism for doing that.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
that's a plan I could easily support. BTW, it would be "nice" when we're all set up if we could make "regular boost" a part of the sandbox...so we could get everything with one update... or some mechanism for doing that.
That mechanism is svn:externals. In this context, commits not propagating are a good thing. Also, check the gcc development mailing list -- they've been discussing a move to Subversion. -- Pedro Lamarão
On Thu, 21 Apr 2005 15:35:30 -0700, Victor A. Wagner Jr. wrote
Comments?
that's a plan I could easily support. BTW, it would be "nice" when we're all set up if we could make "regular boost" a part of the sandbox...so we could get everything with one update... or some mechanism for doing that.
Interesting. If there is a way we could set up the subversion branches to allow sandbox/beta libraries to be optionally available it could open up a whole new approach to library development where we give access to new authors before the review and allow them to develop libraries 'right in place'. And reviewers/regression testers could get the new libraries much earlier in the development cycle. I know nothing about how this might be accomplished with subversion branching, but I think it would be a huge win if we could make it work. Jeff
Beman Dawes wrote: [snip] I don't know if this helps, but the kde project is currently changing to subversion. They have been running a test Repository for about half a year now, and will probably change their main repository this month. I don't know exactly who has been coordinating these efforts, but I think it was Stephan Kulow <coolo () kde ! org>, and the whole issue was probably discussed at the kde-core-devel list. Perhaps they can share some tips. HTH Fabio
"Fabio Fracassi" <f.fracassi@gmx.net> wrote in message news:d4b8hq$raa$1@sea.gmane.org...
Beman Dawes wrote: [snip]
I don't know if this helps, but the kde project is currently changing to subversion. They have been running a test Repository for about half a year now, and will probably change their main repository this month. I don't know exactly who has been coordinating these efforts, but I think it was Stephan Kulow <coolo () kde ! org>, and the whole issue was probably discussed at the kde-core-devel list.
Perhaps they can share some tips.
HTH
Hearing about other's plans and experience definately helps, even second hand. Thanks, --Beman
Hi,
Doug Gregor will lead the effort, and will be the contact at IU when issues arise. Hopefully Troy Straszheim can help, given that he has already setup a Boost SVN repository.
I'd be glad to help. What concerns me most is the directory structure. Referring to the thread "Subversion experiences from the field": if boost wants to do something like that, things will indeed have to be moved around. There wasn't much discussion of this, I'm wondering what people think. There are big implications for developers (I can release versions of my library independent of the rest of boost, or in coordination with subsets of boost), release managers (who would manage a list of component libraries/versions, and would not be required to branch the entire archive for release at some particular instant in time), and users (for instance, as a user I could check out only a certain version of shared_ptr, if that is all I wanted...). Not clear to me if this is all upside, or chaos in the making; my gut feeling is that it is mostly upside but could be screwed up spectacularly if not well understood. If the consensus were to really rearrange things in the archive, one might want to get a 1.33 release out of CVS first, then immediately afterward importing thing into SVN and take one's time getting them organized. (Having done a few trial runs while 1.33 gets out the door.) Just FWIW, -t Beman Dawes wrote:
Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week.
(I've been using Subversion on my machine for about a month, and quickly became convinced it is superior to CVS.)
Points discussed included the importance of a slow, step-by-step approach, because of the importance to Boost and to individual developers, and the need to build familiarity before diving in head first.
Some of the possible tasks to be accomplished before a final conversion:
* Research any remaining questions from Boosters regarding Subversion.
* Decide on the repository directory structure - follow Troy's lead or maybe something else? (One of the advantages of Subversion is that the repository directory structure isn't hard-wired, but that means we have to decide which approach is best.)
* Set up a trial repository, like the one Troy set up, but on the actual machine at IU.
* Set up write authorization. This might be a good time to prune the write-access list to those still active.
* Load test. (Maybe set a time, and have a bunch of Boosters hit the repository at the same time?)
* Make final go/no-go decision. This probably involves both discussion on the list and polling the moderators (as the closest thing we have to a steering committee.)
* Put change notifications in place.
* Verify that backup (tarball or whatever) procedures are in place and functioning.
* Update Boost documentation which refers to the source repository.
* Schedule and execute the actual changeover.
Comments?
--Beman
PS: The book "Version Control with Subversion" by Collins-Sussman, Fitzpatrick, and Pilato, is worthwhile, either in hard copy (O'Reilly) or download from http://svnbook.red-bean.com/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
troy d. straszheim wrote:
If the consensus were to really rearrange things in the archive, one might want to get a 1.33 release out of CVS first, then immediately afterward importing thing into SVN and take one's time getting them organized. (Having done a few trial runs while 1.33 gets out the door.)
As moving files/directories is trivial with svn, I think the transition from cvs to svn can be handled independently from any repository layout change. Thus, the current focus should be cvs -> svn. Everything else can then be worked out incrementally. Regards, Stefan
participants (14)
-
Beman Dawes -
Caleb Epstein -
David Abrahams -
Fabio Fracassi -
Fernando Cacciola -
Jeff Garland -
pedro.lamarao＠mndfck.org -
Rene Rivera -
Robert Mathews -
Russell Hind -
Stefan Seefeld -
troy d. straszheim -
Victor A. Wagner Jr. -
Vladimir Prus