On Mon, Jul 14, 2014 at 11:27 AM, Frank Loeffler knarf@cct.lsu.edu wrote:

Barry prepared a test conversion of CactusBase, including 'trunk/master' and ET_2014_05 so far. A few minor issues were noted:

• empty one-line logs: will be fixed
• empty authors: ok (from cvs2svn)
• thorn-prefixes to be changed from "[thorn] " to "thorn: "
• all branches will be included in next test
• assumption: branch creation among thorns at "same time" -> probably ok, and if not conversion scripts will complain

I have now finished the conversion for two of the arrangements, CactusBase and CactusNumerical. The results can be seen at: https://bitbucket.org/barrywardell/cactusbase https://bitbucket.org/barrywardell/cactusnumerical

One minor issue which appeared during the conversion is that there were a few branches and tags which appear to be a result of a less-than-perfect CVS->SVN conversion. This does not affect any of what I could consider the "important" branches and tags, i.e. for ET and Cactus releases. Except in a couple of cases where these branches are clearly useful, I have omitted them from the merged repository.

The conversion is mostly scripted, although there are necessarily a couple manual cleanup steps at the end. This manual cleanup is a somewhat time-consuming process, so if the new repository layouts look good to everyone it would be nice to transition to them soon-ish, before too much development happens in the thorn svn repositories.

Barry

On Wed, Jul 16, 2014 at 11:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:

I am curious which steps have to be manual. If this is already a problem for CactusBase - how much of a problem will it be for larger repositories? CactusBase is probably one of the "better behaved" places.

The manual steps are to fix some minor inherent issues with the repositories, most of which seem to be a result of the CVS->SVN transition. I'm calling them minor as none of them affect the trunk/master branch or any of the Cactus or ET release branches. Some examples can be seen in the Cartoon2D repository < https://bitbucket.org/cactuscode/cactusnumerical-cartoon2d/commits/all?page=...

:

* There are extra branches (e.g. start, v1) which are not in any way connected to the rest of the history. These were created by the cvs2svn script. * Some of the commits creating tags also introduce changes to the tree (files). These commits were automatically created by the cvs2svn script. * 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).

The reason these steps are manual is it because they require human intervention to determine whether the issues are important or can be ignored.

Could you suggest an example of a more "badly behaved" arrangement?

Barry

On Thu, Jul 17, 2014 at 10:24 AM, Frank Loeffler knarf@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%3E. 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

They look good to me. Should we distribute a commit-msg hook for the client to enforce the policy "Thorn:" in the commit messages? and on top of that set up the server to reject unformatted messages?

In any case, I vote to move these repos to git asap.

Cheers, Bruno.

On 07/17/2014 02:10 AM, Barry Wardell wrote:

On Mon, Jul 14, 2014 at 11:27 AM, Frank Loeffler knarf@cct.lsu.edu wrote:

...

Barry prepared a test conversion of CactusBase, including 'trunk/master' and ET_2014_05 so far. A few minor issues were noted:

• empty one-line logs: will be fixed
• empty authors: ok (from cvs2svn)
• thorn-prefixes to be changed from "[thorn] " to "thorn: "
• all branches will be included in next test
• assumption: branch creation among thorns at "same time" -> probably ok, and if not conversion scripts will complain

I have now finished the conversion for two of the arrangements, CactusBase and CactusNumerical. The results can be seen at: https://bitbucket.org/barrywardell/cactusbase https://bitbucket.org/barrywardell/cactusnumerical

One minor issue which appeared during the conversion is that there were a few branches and tags which appear to be a result of a less-than-perfect CVS->SVN conversion. This does not affect any of what I could consider the "important" branches and tags, i.e. for ET and Cactus releases. Except in a couple of cases where these branches are clearly useful, I have omitted them from the merged repository.

The conversion is mostly scripted, although there are necessarily a couple manual cleanup steps at the end. This manual cleanup is a somewhat time-consuming process, so if the new repository layouts look good to everyone it would be nice to transition to them soon-ish, before too much development happens in the thorn svn repositories.

Barry

---

Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

On Thu, Jul 17, 2014 at 10:19 AM, Frank Loeffler knarf@cct.lsu.edu wrote:

We could provide one. We cannot enforce people installing it.

...

and on top of that set up the server to reject unformatted messages?

That is probably the better option. Although I would only see it as help to "not forget about it", not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the ":" (we might have commit touching multiple thorns), so we cannot technically prevent something like "somewhere: changed something". But we don't need to technically enforce everything anyway.

This is a good point. While it seems like a good general guideline to have the thorn name as a prefix in any commit message, I'm not convinced it is a good idea to strictly enforce it. For example, what about commits that modify several thorns at once?

Carpet has a policy like this; in general commit messages are prefixed by the thorn name, but occasionally there will be a message which changes many thorns at once and doesn't adhere to this convention.

I don't believe in automated mechanisms.

Carpet has been using this policy for a long time. Many people use it without being told. Others don't -- they either don't care, or they can't be bothered because they have other things in mind when creating a commit, or they simply don't believe in reading commit messages.

And then, there is the more important issue of knowing how to write a good commit message. Some people document their changes in commit messages (because they didn't write comments), others simply describe the changes in detail (as opposed to giving a high-level overview). Some use commit messages as forum to announce new features, or to explain how to use a new feature.

If we truly want to change this, then we should - have a discussion on how we would like commit message to read - write this up on a brief, simple wiki page - refuse patches if the commit message is far below our standards (e.g. is offensive, or "forgets" to mention a major issue)

To make this work, we need patches that are submitted together with submit messages. That is, people would need to publish their commits (e.g. in a Bitbucket clone), and a maintainer pulls them.

-erik

On Jul 17, 2014, at 15:31 , Bruno Coutinho Mundim bcmsma@astro.rit.edu wrote:

On 07/17/2014 04:35 PM, Barry Wardell wrote:

...

On Thu, Jul 17, 2014 at 10:19 AM, Frank Loeffler knarf@cct.lsu.edu wrote:

...

We could provide one. We cannot enforce people installing it.

...

and on top of that set up the server to reject unformatted messages?

That is probably the better option. Although I would only see it as help to "not forget about it", not an enforcement really (although technically it is the same). We cannot disallow anything else than thorn names before the ":" (we might have commit touching multiple thorns), so we cannot technically prevent something like "somewhere: changed something". But we don't need to technically enforce everything anyway.

This is a good point. While it seems like a good general guideline to have the thorn name as a prefix in any commit message, I'm not convinced it is a good idea to strictly enforce it. For example, what about commits that modify several thorns at once?

Then we could prefix with "Arrangement:". In any case I don't have strong feelings about it. It was just a suggestion to make the commit messages neater and motivate people to apply localized, atomic commits instead.

Cheers, Bruno.

...

Carpet has a policy like this; in general commit messages are prefixed by the thorn name, but occasionally there will be a message which changes many thorns at once and doesn't adhere to this convention.

---

Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users