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.

I do not understand how this changes workflow. It does not change mine at all.

My workflow relies on being able to push and pull from repositories. We can

still do this. We do gain reliability, and backups.

Please explain what we cannot do now.

Matt

If we have to create multiple accounts to better organize repos - so
be it..

Satish