On Thu, 9 Feb 2012, Sean Farley wrote: > > > > Hg named branches are kind of screwy and bookmarks (which are less screwy) > > are still an "extension" > > > > This is true. Named branches are directly inherited from older versioning > systems (cvs, svn, etc.). After 2.0 Matt Mackall was convinced that > bookmarks so be completely analgous to git's branching: > > $ hg branch foo > marked working directory as branch foo > (branches are permanent and global, did you want a bookmark?) > > Mercurial 2.1 includes fixes that move and update bookmarks automatically > (and also allow pulling divergent bookmarks: foo at 1, foo at 2) > > so it makes sense to have separate clones to use for release management. > > But these releases get merged back, so just tagging them would place the > > tarball in the right place. > > > > Righto. > > > > But PETSc release tarballs include generated documentation, so using > > bitbucket's auto-generated tag-tarballs is not enough for releases. > > > > Ah, that's right. I think this could be fixed by using the tag info in the > scripts that generate the documentation.
Sure alternatives are possible. I guess the primary question is: is are you suggesting this alternate workflow - just becuase its possible - or because its better? This conversation started off with solving a different problem - and then turned into changing workflow. We have a decent workflow currently - and the whole change of workflow [eventhough its possible] -I don't think buying us much. And I suspect it has additional complexity which some of us don't want to deal with. If we have to create multiple accounts to better organize repos - so be it.. Satish
