[petsc-dev] petsc-dev on bitbucket

[Satish Balay]

On Thu, 9 Feb 2012, Matthew Knepley wrote:

> On Thu, Feb 9, 2012 at 8:59 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > 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.
> >
> 
> 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.

this part of the conversation is more about changing workflow wrt throwing
away 'release clones' and maintain all release patches in a single clone
[initially a single dev clone - and later modified to a single release
and single dev clone]


satish