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@1, foo@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