To users of petsc-dev,

      I promised more details on the planned change and why we are making them. 

      The plan is to move petsc-dev over to the git repository system 
(remaining on bitbucket.org so no new accounts are needed) with a simple and 
slow transition from Mecurial and allowing people to change their workflows 
slowly and easily and NOT to drop a totally new system onto everyone at the 
same time. Thus on Tuesday we will be moving all the data over to git and 
providing access from bitbucket.org with BOTH hg and git, you will not need to 
switch over to git on Tuesday and in fact we recommend not switching to git 
immediately but continuing to use hg (on the new repository) until we have the 
git process documented and can help people with it. On Tuesday we will be 
sending out the URL of the new hg repository you should clone from at that 
time. 

   If you are in the middle of a coding project that you don't want to push 
immediately send us petsc-maint at mcs.anl.gov and we'll get things organized 
so that you can continue with that in the new repository.

   Schedule:
      Tuesday -- delete your current petsc-dev repositories and reclone with hg 
using the new URL, use this new repository just like the current one
      After Tuesday -- read our documentation on using Git (to be sent out 
later)  and then eventually switch to accessing petsc-dev via git.
      Eventually -- the Mecurial (hg) access to petsc-dev will become read only.

   Reasons for the change:

1)  We want to provide a more stable version of petsc-dev. To often petsc-dev 
won't compile cleanly when pulled. In our new model this will happen much less 
often since code will be well tested before being pushed into the stable 
version.

2) The petsc-dev repository has gotten overly large due to many large binary 
files being accidentally added to the repository, thus it is time to get rid of 
those files and that requires a reclone.

3) We would like to make the change sets and histories in petsc-dev be more 
logically related to particular projects and not just a random bunch of 
unrelated changes (as Barry has often done). Our new work flow with git will 
help with this. 

 4) Though Mecurial is a user friendly system, git appears to have more 
community support and thus is likely to have more capabilities and utilities 
developed for it in the future. We will strive to make the use of git with 
PETSc as simple as possible. 

   I have been hesitant to make this change for fear that working with 
petsc-dev would become more cumbersome, more annoying, more bookkeeping 
involved, more like a job, and hence less fun. And we know people tend to do 
something less if it is less fun. Since we don't want people to do things with 
petsc-dev less we will be trying hard to make the new model as close to the old 
model as possible and not cumbersome or annoying.  As always we appreciate any 
feedback on what we are doing wrong and how we could improve it.

   Barry


On Mar 10, 2013, at 10:29 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> 
>    To everyone accessing petsc-dev via Mecurial (hg),
> 
>      We are reorganizing how we handle the petsc-dev/BuildSystem repository. 
> In step one everyone will need to delete all their clones of petsc-dev and 
> then reclone them either on Tuesday or soon after. So it would be good if 
> anyone who has material close to being ready to push to petsc-dev to finish 
> it up and push it before then.** (If you are a user of petsc-dev but do not 
> edit any files in petsc-dev you will also need to do the reclone.)
> 
>    We will send out more warnings reminding you of the change and the 
> location of the new URL to clone from. We will also send out a more complete 
> message explaining all the planned changes and why we are making them. Aside 
> from this first recloning, the changes will not require any immediate change 
> in the way you interact with petsc-dev.
> 
> 
>   Barry
> 
> ** If you miss the deadline, but have changes that still need to be 
> submitted, we can handle that but it will be  manual process so we do not 
> want too much of that.
> 

Reply via email to