case wrote:
> On Fri, Feb 11, 2011, Scott Brozell wrote:
>> I notice that some published bugfixes for AT 1.4 have been committed
>> into the amber11 branch, eg bugfix 10, and some have not, eg bugfix 6.
>> Is there a specific protocol ?
>
> No. You could write one, i.e. a "how to" create a bugfix (that includes
> updating the amber11 branch) and put it on the wiki.
>
> I'd go ahead and push bugfix 6 to amber11 as well.
>
> ...thx...dac
>
At this moment in time, the amber11 branch has lost sync with the
published bugfixes; e.g.
$ cd $AMBERHOME
$ git checkout amber11
$ git log
cf. with
http://ambermd.org/bugfixes11.html
These are out of order and there are some patches that exist on the
website, but do not actually exist in the amber11 tree, e.g. some of the
CUDA related patches.
This is a shame since I envisaged a one to one mapping between the the
commits in the amber11 branch and each bugfix. Hence, checking out the
amber11 branch would give you a version of amber11 that has all these
applied.
I think the situation is further complicated by the fact that we are
projecting two codebases from one tree i.e. amber11 contains itself, its
own bugfixes, ambertools1.4. (at14) and some of at14 bug fixes. This
will soon be ambertools1.5 (at15) and I'm really not sure how this will
all work in the current form.
The current branch status is as follows:
$ git branch -lr
origin/CNNRCW
origin/HEAD
origin/MMPBSApy-dev
origin/MTKpp-devel
origin/amber11
origin/config-devel
origin/master
origin/pbsa-dev
origin/remove-warnings
origin/rism-dev
origin/xray
origin/master = current state of the amber git tree
origin/amber11 = A branch of the master at the point when amber11 was
release. Contains, in some form some of the published bugfixes.
We could create a new branch of the master at the point of amber11's
inception and call it at14, and then apply only the at14 bugfixes to
that branch. The only issue is that I don't know how to branch a subset
of a tree and for the moment, I plan to work around it by just branching
the entire tree.
When at15 lands, we could branch the master branch at that point in time
to at15 and then start to apply at15 related bugfixes to that at15
branch as time goes on. Meanwhile, *only* amber11 related bug fixes
would be applied to the amber11 branch.
With respect to the current amber11 branch status, I could try to rebase
it to clean it up (i.e. ensure a one to one mapping and remove any at14
fixes), but I'd like to a practice on a backup first.
What do people think?
Regards,
Mark
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Feb 11 2011 - 06:30:02 PST
