Present: Erik, Steve, Roland, Frank, Peter, Ian
Formaline: * Formaline seems very slow, we suspect this to be due to either larger files being added to tarballs and/or Roland's change that circumvents gits internal caching * suggested solutions include undoing the commit and trying to work around file systems that do not support hard links as well as tighter integration of Formaline with the flesh make targets to start Formaline's processing early * Formaline misses adding Makefile to the tarball, a workaround is to tar up the flesh repo directly by first de-referencing Makefile (if it is a symbolic link), then including the directory containing that file in the tarball. This should work for common situations
Having a moving release branch: * Roland had suggested having a moving release branch so that eg websites could refer to that branch rather than having to be updated after each release, the hope is also to offer a simpler update path than "wipe your old Cactus tree and download a new one" * a suggestion is to only have such a branch in the manifest repo and nowhere else * Ian dislikes the idea of a moving branch since he fears it will interact badly with git pull * Erik points out that git pull will report conflicts if the release branch jumps from one release to the next and suggests to use a tag instead, Roland thinks this will not happen and will test this with locally and report back * having a simpler way to point to the current release is agreed to be nice but no simple way to achieve this seems obvious
There was also a discussion of the piraha-everywhere branch. Frank
reported that it worked for him without trouble for his non-ET thorns.
Peter has privately reported the same to me. Frank said he plans to
go over the patch and understand it in more detail when he gets back
to the office.
Cheers,
Steve
On 08/22/2016 10:31 AM, Roland Haas wrote:
Present: Erik, Steve, Roland, Frank, Peter, Ian
Formaline:
- Formaline seems very slow, we suspect this to be due to either larger files being added to tarballs and/or Roland's change that circumvents gits internal caching
- suggested solutions include undoing the commit and trying to work around file systems that do not support hard links as well as tighter integration of Formaline with the flesh make targets to start Formaline's processing early
- Formaline misses adding Makefile to the tarball, a workaround is to tar up the flesh repo directly by first de-referencing Makefile (if it is a symbolic link), then including the directory containing that file in the tarball. This should work for common situations
Having a moving release branch:
- Roland had suggested having a moving release branch so that eg websites could refer to that branch rather than having to be updated after each release, the hope is also to offer a simpler update path than "wipe your old Cactus tree and download a new one"
- a suggestion is to only have such a branch in the manifest repo and nowhere else
- Ian dislikes the idea of a moving branch since he fears it will interact badly with git pull
- Erik points out that git pull will report conflicts if the release branch jumps from one release to the next and suggests to use a tag instead, Roland thinks this will not happen and will test this with locally and report back
- having a simpler way to point to the current release is agreed to be nice but no simple way to achieve this seems obvious
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
There was also a discussion of the piraha-everywhere branch. Frank reported that it worked for him without trouble for his non-ET thorns. Peter has privately reported the same to me. Frank said he plans to go over the patch and understand it in more detail when he gets back to the office.
Right there was, sorry.
On the release-branch issue:
I tried this and unfortunately it is exactly as Erik described it: git finds conflicts if there are commits in only some of the release branches but not in the others.
Tags seems less nice to use since they don't allow for a git pull (at best I guess one has to do another git checkout) which is one of the interesting parts.
In this light a "release" tag for the manifest maybe the simplest solution.
Yours, Roland
On 22 Aug 2016, at 17:43, Roland Haas rhaas@illinois.edu wrote:
Hello all,
There was also a discussion of the piraha-everywhere branch. Frank reported that it worked for him without trouble for his non-ET thorns. Peter has privately reported the same to me. Frank said he plans to go over the patch and understand it in more detail when he gets back to the office.
Right there was, sorry.
On the release-branch issue:
I tried this and unfortunately it is exactly as Erik described it: git finds conflicts if there are commits in only some of the release branches but not in the others.
Tags seems less nice to use since they don't allow for a git pull (at best I guess one has to do another git checkout) which is one of the interesting parts.
In this light a "release" tag for the manifest maybe the simplest solution.
Tags also cannot be moved; that is the point - they always point to the same version.
-- Ian Hinder http://members.aei.mpg.de/ianhin
Hello all,
Tags also cannot be moved; that is the point - they always point to the same version.
I agree, they *shouldn't* be moved and are not designed to be. You can however delete and re-create them, which would be sufficient for our purpose since all we want is a single name that can move along with the releases.
Yours, Roland
On Monday 22 August 2016, Roland Haas rhaas@illinois.edu wrote:
Hello all,
Tags also cannot be moved; that is the point - they always point to the same version.
I agree, they *shouldn't* be moved and are not designed to be. You can however delete and re-create them, which would be sufficient for our purpose since all we want is a single name that can move along with the releases.
Tags are really not designed with this in mind, so weird things can and do happen if you do this sort of thing.
There are robust solutions to this generic issue. They usually revolve around a particular workflow. The most popular one is git-flow; see e.g. https://www.atlassian.com/git/tutorials/comparing-workflows for a good overview.
I'm not necessarily advocating that th ET change workflow, but it could be worth considering.
Barry
users@lists.einsteintoolkit.org
-
Barry Wardell -
Ian Hinder -
Roland Haas -
Steven R. Brandt