[Users] Einstein Toolkit Meeting Minutes

[Erik Schnetter]

It seems we're trying to achieve two separate and -- apparently -- inconsistent things during our conversion to git:

(1) Create a git repository that can be used to go backwards in time, even to time where we used svn and cvs instead of git
(2) Faithfully record the history of the previous svn and cvs repositories in a git repository

I would choose (1) over (2) at any time. We can simply keep the original svn and cvs repositories around -- even as tarball of the server database if necessary -- for those rare times where the original history is relevant. For most other times, slight changes to the history are fine.

For example, I would not mind creating additional commits to ensure tags are consistent. Similarly, having "strange" branches / tags around should not matter; we can simply create a subdirectory "history" for them, and then manually move a few (interesting) branches or tags out of this subdirectory (e.g. the previous official releases, or currently active feature branches).

-erik

On Jul 18, 2014, at 11:11 , Barry Wardell <barry.wardell at gmail.com> wrote:

> On Thu, Jul 17, 2014 at 10:24 AM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
> > * Some of the commits creating tags also introduce changes to the tree
> > (files). These commits were automatically created by the cvs2svn script.
> 
> Why is that a problem? Does the conversion choke if commits do multiple
> things at once?
> 
> The problem is that tags are not commits, they are supposed to be permanent pointers to a specific commit. They are never supposed to change and they cannot introduce changes to the tree. This is conceptually the same in svn, but not strictly enforced (since tags are really just copies of the code at another point in the svn directory tree).
> 
> The problem happens when multiple thorns each have tags which also contain changes to the tree. A tag is just a pointer to a commit and can't point to two different commits at the same time.
> 
> The solution I've used in instances where this happens is to create a new branch and merge all of the commits into that branch.
> 
> > * Some branches/tags (e.g. STABLE, LATEST) were not created at the same
> > time across different repositories. None of the ones that I encountered had
> > what I would useful content (e.g. having a STABLE tag pointing to some
> > point long in the past is not particularly useful).
> 
> I agree. We would very likely be better off without them.
> 
> That makes things easier. I have a full list of tags/branches that have been omitted from the merged repositories so that we're sure we're not missing something. Right now that list is (not all of these are present in all arrangements/thorns):
> 
> Branches:
> start
> El-Kharma
> dp
> 
> Tags:
> LATEST
> STABLE
> v1
> v_1
> r1
> V1
> JTHORN_INIT
> JT_2002_08_18
> jthorn_20050318
> gr_qc
> LOCALINTERP_INIT
> Rel-0-1
> 
> I have now finished converting all of the repositories listed in the Version Control page of the wiki <https://docs.einsteintoolkit.org/et-docs/Version_control>. The results are available at:
> https://bitbucket.org/barrywardell/cactustest
> https://bitbucket.org/barrywardell/cactuspugh
> https://bitbucket.org/barrywardell/cactusnumerical
> https://bitbucket.org/barrywardell/pittnullcode
> https://bitbucket.org/barrywardell/cactusbase
> 
> A couple of minor things came up in the conversion process:
> 
> * I created a merged CactusNumerical as a more difficult test than CactusBase before noticing that it wasn't listed on the wiki page. It may be that we don't need this arrangement merged.
> * I included both CactusPUGH and CactusPUGHIO thorns (IOHDF5 and IOHDF5Util) in the same arrangement. It may be that they should be kept separate.
> 
> Barry
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users

-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20140718/f39117cf/attachment.bin