Present: Frank, Roland, Peter, Erik, Matt, Ian, Josh, Maria, Yosef, Philipp
git to svn transition:
* Ian (and other contributors) created a wiki page outlying ideas for how to organize repositories: https://docs.einsteintoolkit.org/et-docs/Version_control
* majority of call participants prefer git over svn, points mentioned are easier management of branches and patches and availability of powerful GUIs * suggest using GUIs even for "advanced" users. For git there is SourceTree for OSX and SmartGit or GitEye (see http://git-scm.com/downloads/guis)
Goals to achieve while moving the repositories, some of which might be conflicting, in no particular ordering: * simplify exchanging patches, in particular patches for review where right now we exchange patch files, instead we might want to point to a revision in a branch or private repository * consistency of thorns in toolkit is easier to achieve is strongly dependent thorns are in a single repository * simplify work-cycle for developers, read-only access for end-users is already provided by GetComponents * minimize amount of code downloaded * keep modularity of framework, avoid monolithic repository
Opinions: * consistency is given low priority, instead require framework to enforce this (eg via interface.ccl etc). * avoid overly large repository with many unrelated thorns * using branches and cherry picking commits to choose a working set of thorns that mixes cutting edge versions of some thorns and bugfix-only versions of another is hard to do, takes lots of time. * we lack the manpower to keep a always working mainline for all thorns, GRHydro currently follows this paradigm and requires ~0.5 days a week to choose and push patches. The advantage is that Zelmani can do whatever it wants and does not have to worry about "external" users pulling code that contains bugs. This is not in line with the ET philisophy of having trunk branches under development then releases every 6 months.
Hosting: * Frank (who will be admin) advertises to host the git repos at CCT, Ian suggests using gitolite as the front-end which uses a plain git repository for admin task (keeps record of admin actions) * desire to be able to automate actions on multiple repositories (assuming we will have multiple/many repositories) * suggestion to consider bitbucket/github as external hoster for speed and/or certificate issues, did not find much support * want to make sure that certificates work and that speed is acceptable * rather spend some money than spend time * bitbucket might be a viable option when using teams and would simplify infrequent tasks, major problem is scriptability * github source code made be available to use even for locally hosted repos if we want a web-based UI, Ian to test this
Proposed repository structure: * structure not fully decided on, use wiki page (see above) as location to hash out proper layout
Yours, Roland
On Mon, Aug 12, 2013 at 11:47:48AM -0700, Roland Haas wrote:
- majority of call participants prefer git over svn, points mentioned
are easier management of branches and patches and availability of powerful GUIs
Maybe unrelated: but I just tried to add an empty directory to git, and to my surprise find that this doesn't seem to be possible? One of my motivations to switch from CVS to Subversion was that it enabled me to delete empty directories. And now I cannot add them with Git - or is there some way to do it?
Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Frank,
Maybe unrelated: but I just tried to add an empty directory to git, and to my surprise find that this doesn't seem to be possible? One of my motivations to switch from CVS to Subversion was that it enabled me to delete empty directories. And now I cannot add them with Git - or is there some way to do it?
You cannot have empty folders (or empty files) in git. The issue is that git tracks content not files. So an empty folder does not exist as far as Git is concerned.
See http://stackoverflow.com/questions/115983/how-do-i-add-an-empty-directory-to...
Yours, Roland
- -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
On Mon, Aug 12, 2013 at 03:08:55PM -0700, Roland Haas wrote:
You cannot have empty folders (or empty files) in git. The issue is that git tracks content not files. So an empty folder does not exist as far as Git is concerned.
That's what I also found when I googled. I wondered if someone might have fixed that already. Apparently not. In my mind directories are content as well, like file names and file properties ect.
Frank
On 12 Aug 2013, at 20:47, Roland Haas roland.haas@physics.gatech.edu wrote:
Present: Frank, Roland, Peter, Erik, Matt, Ian, Josh, Maria, Yosef, Philipp
- desire to be able to automate actions on multiple repositories
(assuming we will have multiple/many repositories)
- suggestion to consider bitbucket/github as external hoster for speed
and/or certificate issues, did not find much support
- want to make sure that certificates work and that speed is acceptable
- rather spend some money than spend time
- bitbucket might be a viable option when using teams and would simplify
infrequent tasks, major problem is scriptability
- github source code made be available to use even for locally hosted
repos if we want a web-based UI, Ian to test this
Actually I volunteered to test using BitBucket hosting for the ET. I am less worried about scriptability now because I discovered that there is a python wrapper (https://bitbucket-api.readthedocs.org/en/latest/bitbucket.html#module-bitbuc...) to the bitbucket REST interface (https://confluence.atlassian.com/display/BITBUCKET/Use+the+Bitbucket+REST+AP...). This means you can write very simple python code to perform operations on bitbucket repositories such as creating them and deleting them. This makes it easier to manage larger numbers of repositories. I have taken some of the existing Git mirrors that Barry and I have been using for 2 years (see http://git.barrywardell.net) and mirrored them to BitBucket. See https://bitbucket.org/einsteintoolkit. This was fairly easy to do with a few lines of bash and python. Write access to the repositories would be handled using BitBucket accounts, and could be managed either globally for the EinsteinToolkit "team", applying to all repositories, or on a per-repository basis if that were necessary. Assuming that we wanted separate Einstein Toolkit and Cactus bitbucket teams, this would be important for Cactus because write access to the flesh would be more strictly controlled than write access to other parts of the code.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
Actually I volunteered to test using BitBucket hosting for the ET. I
I had occasion to look at bitbucket's terms of service and found a wrinkle: the maximum number of users per repository (for free accounts) is 5. Assuming this is also the limit on the number of allowed committers, this would be somewhat limiting.
For the ET where we'd like to have many users with commit rights (eg all maintainers plus possibly all group members from the "authoring" institution) this is a bit of a downside. Kranc for example has 6 contributors and GRHydro for example has likely many more. 25 users are $25/month (https://bitbucket.org/plans?). This is not huge sums of money yet, though we could also consider putting the git based repositories on github where no such restriction exists (and the restriction on public only repositories does not affect the ET).
Yours, Roland
- -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
On Wed, Sep 11, 2013 at 8:16 PM, Roland Haas <roland.haas@physics.gatech.edu
wrote:
Actually I volunteered to test using BitBucket hosting for the ET. I
I had occasion to look at bitbucket's terms of service and found a wrinkle: the maximum number of users per repository (for free accounts) is 5. Assuming this is also the limit on the number of allowed committers, this would be somewhat limiting.
This is only for commercial users. We would qualify for free academic licensing, in which case the number of users is unlimited.
On Wed, Sep 11, 2013 at 8:16 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
Actually I volunteered to test using BitBucket hosting for the ET. I
I had occasion to look at bitbucket's terms of service and found a wrinkle: the maximum number of users per repository (for free accounts) is 5. Assuming this is also the limit on the number of allowed committers, this would be somewhat limiting.
For the ET where we'd like to have many users with commit rights (eg all maintainers plus possibly all group members from the "authoring" institution) this is a bit of a downside. Kranc for example has 6 contributors and GRHydro for example has likely many more. 25 users are $25/month (https://bitbucket.org/plans?). This is not huge sums of money yet, though we could also consider putting the git based repositories on github where no such restriction exists (and the restriction on public only repositories does not affect the ET).
For what it is worth, this is only true for private repositories. For public repositories it is unlimited. We use BitBucket for both Enzo and yt, which have more than five committers each.
https://bitbucket.org/enzo/ https://bitbucket.org/yt_analysis/
Both of these are managed under "Team" accounts, where individuals retain their own accounts but can belong to a collective team organization, manage repositories under that team, and so on.
Yours, Roland
My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlIxB/gACgkQTiFSTN7SboXM0gCdGJskHxCsb+Ov6hUCofw+LC3D 6CMAn2zaUPrsOYmdRlFhdJkSPpUbKOHX =95yh -----END PGP SIGNATURE----- _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
For what it is worth, this is only true for private repositories. For public repositories it is unlimited. We use BitBucket for both Enzo and yt, which have more than five committers each.
https://bitbucket.org/enzo/ https://bitbucket.org/yt_analysis/
Both of these are managed under "Team" accounts, where individuals retain their own accounts but can belong to a collective team organization, manage repositories under that team, and so on.
Thank you both Barry and Matthew. This is good news, I had not realized there that this only applies to private repos or that there is academic licensing.
Yours, Roland
- -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
On 12 Sep 2013, at 03:01, Roland Haas roland.haas@physics.gatech.edu wrote:
Signed PGP part Hello all,
For what it is worth, this is only true for private repositories. For public repositories it is unlimited. We use BitBucket for both Enzo and yt, which have more than five committers each.
https://bitbucket.org/enzo/ https://bitbucket.org/yt_analysis/
Both of these are managed under "Team" accounts, where individuals retain their own accounts but can belong to a collective team organization, manage repositories under that team, and so on.
Thank you both Barry and Matthew. This is good news, I had not realized there that this only applies to private repos or that there is academic licensing.
Yours, Roland
My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
To summarise, my understanding is that BitBucket allows unlimited users for public repositories (our case), and the number of users for private repositories depends on the type of account. Academic accounts (which need a unique academic email address, which cannot be associated with any other bitbucket account) can have unlimited private repositories, whereas "normal" accounts are limited to 5 unless you pay money. This is better than Github, which does not allow any private repositories at all unless you pay money.
I created both "einsteintoolkit" and "cactus" BitBucket team accounts a while ago and put some Git mirrors of the current SVN repositories there for testing.
On Mon, Aug 12, 2013 at 11:47:48AM -0700, Roland Haas wrote:
- Frank (who will be admin) advertises to host the git repos at CCT, Ian
suggests using gitolite as the front-end which uses a plain git repository for admin task (keeps record of admin actions)
In order to test setup on the ET servers I've taken one of the probably largest repositories within the toolkit (carpet) and cloned it on the ET server, despite that we actually won't be hosting this particular repository there.
For anonymous clones, use
git clone http://svn.einsteintoolkit.org/git/carpet
A few developers got write access as well, which would simply use
git clone https://svn.einsteintoolkit.org/git/carpet
Please try to clone from this and report problems if there are any.
For people with interest in background information: This uses smart-http as transport (as fast as ssh), apache for authentication (as usual), gitolite for authorization with a admin repository for easy configuration. By default it uses the regular CCT account information (passwords), but if you like we could change that to be different if you like.
Frank
users@lists.einsteintoolkit.org
-
Barry Wardell -
Frank Loeffler -
Ian Hinder -
Matthew Turk -
Roland Haas -
Roland Haas