2008/5/24 Frank Birbacher <bloodymir.crap@gmx.net>:
Hi!
James Sharpe schrieb:
Besides I don't think that subversion would move away from using paths for branches since its at the very core of how it has been designed (the model seems attractive at first but in reality it becomes a pain as it allows users to do very silly things to the repository)
Attractive Model? Can Do Silly Things? That's the same as with C++, isn't it?
Indeed albeit one that most people are less familiar with the silly things that can be done(and also that they only bite further in time)
The flaw IMO is that the svn up does not follow renaming. But you would only want it if the root of your working copy moved. If only a subdir moved, i.e. current location was deleted, you don't want svn to switch your subdir to the new location.
There are issues with svn. But the model is simple and works quite well. Just because the "svn up" command doesn't cope with renames, well, just always use "svn switch $MY_SVN_URL@HEAD ."
Point taken, but its far from ideal since it requires me to remember the url or look it up when I need to update. Yes it is a simple model that works for the most part, but currently makes things harder than it needs to be when it comes to merging changes; just try a distributed VCS and you'll see how easy merging becomes, and in fact also how much easier branches are too for that matter. Don't get me wrong subversion is a great tool, but I think that the next generation is taking over; its reminiscent of the move of projects from cvs to svn; a lot of projects said cvs works fine for us until they made the move, at which point the benefits of svn became clearer. I believe we're seeing a similar move with distributed version control systems, which in general is an enabling tool for open source; it enables easy forking, branching and contributions, and in fact promotes higher quality patches and history due to history rewriting and being able to commit offline(which for me is one of the biggest advantages of using a DVCS over subversion; I can keep local patches in my own repository until they're tested and proven ready for integration upstream) Take a look at Linus' presentation on git http://www.youtube.com/watch?v=4XpnKHJAok8 for more information on how git differs from CVS/SVN. Anyway I feel this discussion is wandering OT, since we've lost focus on the topic at hand: the release process; the fact is we can use DVCS (be it git, bzr etc...) over the current subversion repository (conversion to these tools can be considered at a later date once a few developers have experience of using them for boost) and that these tools help in easing merging of branches, which is IMO the key part of easing the release process. Obviously one of the biggest consideration when we start to talk about more use of branches is that of testing; how do we distribute our testing resources sufficiently over the branches? This is where I think that branching from trunk as the next stable release as opposed to release is an advantage. Current policy states that regression tests on trunk must be stable before being merged to release, but obviously where library interdependencies come into play this change might not be quite so stable on the release branch, I think that branching from trunk is a better policy and then reverting changesets that cause regressions, at point of release, if they can't be fixed. This is a similar model to what the kernel uses: have a merge window in which some destabilization is allowed. The remainder of the release time is then stablization of the release. The way I would envisage this style of process working for boost is: * stable feature additions/bug fixes occur to trunk at any point in the release cycle * on a given date(on day of release of first of previous release series - there's no point in waiting to branch!) trunk is branched to the next release branch (this date is made know well in advance so developers know that towards this date they should be stablizing regression tests on trunk ready for the branch) Release testing resources begin testing this branch (these release testers should run at least once a day, but preferably on every commit) * this release branch is used for a series 1.x.y - 1.x.z, a release manager is assigned to look after this branch of releases * the first release 1.x.0 is released with a similar process from the six weeks mark that Beman describes at http://svn.boost.org/trac/boost/wiki/ReleaseSchedule although the timescale can now be modified to lengthen the bug fix changes - there should be NO new features(and in most cases no changes to the API - this gives a longer period for documentation to be checked) added though since this should be done on trunk before the release. After a certain date (maybe 4 weeks before release) if a feature is still causing large regressions at the discretion of the release manager this change can be reverted. * Once the release is done the testers for this release branch are reduced to an on commit testing regime (they will also now be testing for the next release branch that has just been created) and this branch is now only committed to for regressions from the release state of the regression tests and bug fixes filed against the last release in trac. No other commits should be allowed on this branch. Then point releases are made fortnightly while there are fixes to be released - this branch is of lower priority with the testers ( but should additional resources become available then more frequent tests can occur) * In this scheme development of potentially disruptive or breaking changes should be initially developed on a branch (using distributed tools this could in fact be a potentially non-publically visible branch - which can then be rebased as a series of commits against trunk). This can then be merged into trunk just after a release branch has been created in order to maximise the time for stabilizing this change against the regression tests. Comments on this as a proposed release structure?