Hi,
with the new release of the Einstein Toolkit complete, I think we can finally complete the transition of GetComponents to GitHub. This would involve two things.
1. Applying the attached patch to the ET trunk thornlist. It would just add the GetComponents GitHub repository, and symlink GetComponents into the root of the ET source tree. There was an issue with this previously, where the symlink did not work, but that was fixed a few months ago.
2. Deleting the svn version of GetComponents in utils/Scripts.
There would be no functional changes to GetComponents as the two versions are mirrored, users would simply have to call GetComponents from the root directory now.
Eric
On Wed, Dec 1, 2010 at 7:15 PM, Eric Seidel eric@eseidel.org wrote:
Hi,
with the new release of the Einstein Toolkit complete, I think we can finally complete the transition of GetComponents to GitHub. This would involve two things.
- Applying the attached patch to the ET trunk thornlist. It would just add
the GetComponents GitHub repository, and symlink GetComponents into the root of the ET source tree. There was an issue with this previously, where the symlink did not work, but that was fixed a few months ago.
Eric
Yes, this would be a good time to do this.
Most other tools are distributed as directories residing in the root level of the Cactus source tree. (We're actually beginning to have too many of these, but we can deal with that later.) I think GetComponents should be handled in the same way, and would omit the symlink. What may be a good idea is to introduce a "bin" directory in the Cactus source tree and put copies/links of all the tools there.
The GetComponents directory would also need to contain documentation and a README; the documentation could also be a copy of or an abstract of a web site.
Who has write permission to the github repository? It is always good if one or two external people (i.e. Einstein Toolkit maintainers that are not the main tool developers) have write permission as well in cases of emergency.
Regarding the issue you mention above: Most people do not update their source tree regularly, and I would not be surprised if some people still stumbled over this problem. Could you make sure there is a description and a work-around available somewhere prominent, e.g. in the README and on the web site?
- Deleting the svn version of GetComponents in utils/Scripts.
There would be no functional changes to GetComponents as the two versions are mirrored, users would simply have to call GetComponents from the root directory now.
Eric
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi,
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
What may be a good idea is to introduce a "bin" directory in the Cactus source tree and put copies/links of all the tools there.
I agree with that. It would be kind of strange to have both bin/ and exe/ (I don't like the name exe/ so much anyway), but I think we could live with that.
Who has write permission to the github repository? It is always good if one or two external people (i.e. Einstein Toolkit maintainers that are not the main tool developers) have write permission as well in cases of emergency.
I think I should have, but never tried. Eric should probably also give you, and a couple of other maintainers access - but I guess he needs to know your github id for that.
- Deleting the svn version of GetComponents in utils/Scripts.
I would not delete it. At the very least I would replace it with a script which prints a message pointing to the new location.
Frank
On Thu, Dec 2, 2010 at 9:45 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
To be clear: I suggest that GitHub should host a repository which consists (at least) of a single directory called e.g. CRL, and this directory should contain (at least) GetComponents, README, and doc.tex. There is no need to copy or link GetComponents to be in the main Cactus directory; one can invoke it as CRL/GetComponents, the way we invoke all other tools (e.g. all the scripts and visualisation helpers in the utils directorye).
-erik
Frank Loeffler wrote:
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
As Frank said, this would not be possible with the way GetComponents handles git repositories. We would have to symlink GetComponents (or a "CRL" directory). I'm not particularly happy with the way this is handled by GetComponents, and I've been thinking about modifying the behavior to place the actual repo in !TARGET unless something is specified in !CHECKOUT, but that is another discussion...
What may be a good idea is to introduce a "bin" directory in the Cactus source tree and put copies/links of all the tools there.
I agree with that. It would be kind of strange to have both bin/ and exe/ (I don't like the name exe/ so much anyway), but I think we could live with that.
I like the "bin" directory idea too.
Who has write permission to the github repository? It is always good if one or two external people (i.e. Einstein Toolkit maintainers that are not the main tool developers) have write permission as well in cases of emergency.
I think I should have, but never tried. Eric should probably also give you, and a couple of other maintainers access - but I guess he needs to know your github id for that.
Both Frank and Erik should have write access to GetComponents on GitHub.
- Deleting the svn version of GetComponents in utils/Scripts.
I would not delete it. At the very least I would replace it with a script which prints a message pointing to the new location.
This is a good idea.
As to Erik's suggestion of placing everything in a single "CRL" directory, that would actually be a more sensible name for the git repository. It also holds my experimental generateCRL script, which generates a component list based on the items you have checked out (only works with cvs and svn so far). I don't know if GitHub allows you to change the name of your repository, but I might change it if they do.
Eric
On Thu, Dec 2, 2010 at 10:35 AM, Eric Seidel eric@eseidel.org wrote:
Frank Loeffler wrote:
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
As Frank said, this would not be possible with the way GetComponents handles git repositories. We would have to symlink GetComponents (or a "CRL" directory). I'm not particularly happy with the way this is handled by GetComponents, and I've been thinking about modifying the behavior to place the actual repo in !TARGET unless something is specified in !CHECKOUT, but that is another discussion...
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
As to Erik's suggestion of placing everything in a single "CRL" directory, that would actually be a more sensible name for the git repository. It also holds my experimental generateCRL script, which generates a component list based on the items you have checked out (only works with cvs and svn so far). I don't know if GitHub allows you to change the name of your repository, but I might change it if they do.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
-erik
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
Eric
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seidel eric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
On Thu, Dec 23, 2010 at 7:25 PM, Eric Seidel eric@eseidel.org wrote:
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
That would be fine too, I thought you had suggested that the entire repository be linked into Cactus/bin.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 23, 2010 1:31 PM
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
Eric Seidel mailto:eric@eseidel.org December 23, 2010 1:25 PM
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 5, 2010 5:09 PM
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seideleric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
Eric Seidel mailto:eric@eseidel.org December 4, 2010 11:26 AM
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 2, 2010 9:40 AM
On Thu, Dec 2, 2010 at 10:35 AM, Eric Seideleric@eseidel.org wrote:
Frank Loeffler wrote:
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
As Frank said, this would not be possible with the way GetComponents handles git repositories. We would have to symlink GetComponents (or a "CRL" directory). I'm not particularly happy with the way this is handled by GetComponents, and I've been thinking about modifying the behavior to place the actual repo in !TARGET unless something is specified in !CHECKOUT, but that is another discussion...
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
As to Erik's suggestion of placing everything in a single "CRL" directory, that would actually be a more sensible name for the git repository. It also holds my experimental generateCRL script, which generates a component list based on the items you have checked out (only works with cvs and svn so far). I don't know if GitHub allows you to change the name of your repository, but I might change it if they do.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
-erik
I updated the patch to link the binary directly into Cactus/bin/GetComponents. If there are no other objections, I would like to apply the patch.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 23, 2010 1:31 PM
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
Eric Seidel mailto:eric@eseidel.org December 23, 2010 1:25 PM
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 5, 2010 5:09 PM
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seideleric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
Eric Seidel mailto:eric@eseidel.org December 4, 2010 11:26 AM
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 2, 2010 9:40 AM
On Thu, Dec 2, 2010 at 10:35 AM, Eric Seideleric@eseidel.org wrote:
Frank Loeffler wrote:
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
As Frank said, this would not be possible with the way GetComponents handles git repositories. We would have to symlink GetComponents (or a "CRL" directory). I'm not particularly happy with the way this is handled by GetComponents, and I've been thinking about modifying the behavior to place the actual repo in !TARGET unless something is specified in !CHECKOUT, but that is another discussion...
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
As to Erik's suggestion of placing everything in a single "CRL" directory, that would actually be a more sensible name for the git repository. It also holds my experimental generateCRL script, which generates a component list based on the items you have checked out (only works with cvs and svn so far). I don't know if GitHub allows you to change the name of your repository, but I might change it if they do.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
-erik
I have applied this patch. Going forward, development of GetComponents will be done on GitHub.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 23, 2010 1:31 PM
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
Eric Seidel mailto:eric@eseidel.org December 23, 2010 1:25 PM
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 5, 2010 5:09 PM
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seideleric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
Eric Seidel mailto:eric@eseidel.org December 4, 2010 11:26 AM
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 2, 2010 9:40 AM
On Thu, Dec 2, 2010 at 10:35 AM, Eric Seideleric@eseidel.org wrote:
Frank Loeffler wrote:
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
As Frank said, this would not be possible with the way GetComponents handles git repositories. We would have to symlink GetComponents (or a "CRL" directory). I'm not particularly happy with the way this is handled by GetComponents, and I've been thinking about modifying the behavior to place the actual repo in !TARGET unless something is specified in !CHECKOUT, but that is another discussion...
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
As to Erik's suggestion of placing everything in a single "CRL" directory, that would actually be a more sensible name for the git repository. It also holds my experimental generateCRL script, which generates a component list based on the items you have checked out (only works with cvs and svn so far). I don't know if GitHub allows you to change the name of your repository, but I might change it if they do.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
-erik
Hi Eric,
would you mind to update the wiki with the appropriate commands (git clone and path) for GetComponents?
Thanks, Bruno.
Eric Seidel wrote:
I have applied this patch. Going forward, development of GetComponents will be done on GitHub.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 23, 2010 1:31 PM
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
Eric Seidel mailto:eric@eseidel.org December 23, 2010 1:25 PM
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 5, 2010 5:09 PM
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seidel eric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
Eric Seidel mailto:eric@eseidel.org December 4, 2010 11:26 AM
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 2, 2010 9:40 AM
On Thu, Dec 2, 2010 at 10:35 AM, Eric Seidel eric@eseidel.org wrote:
Frank Loeffler wrote:
On Thu, Dec 02, 2010 at 08:25:12AM -0500, Erik Schnetter wrote:
I think GetComponents should be handled in the same way, and would omit the symlink.
I wouldn't know how to do that without just coping GetComponents and not having it in a repository.
As Frank said, this would not be possible with the way GetComponents handles git repositories. We would have to symlink GetComponents (or a "CRL" directory). I'm not particularly happy with the way this is handled by GetComponents, and I've been thinking about modifying the behavior to place the actual repo in !TARGET unless something is specified in !CHECKOUT, but that is another discussion...
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
As to Erik's suggestion of placing everything in a single "CRL" directory, that would actually be a more sensible name for the git repository. It also holds my experimental generateCRL script, which generates a component list based on the items you have checked out (only works with cvs and svn so far). I don't know if GitHub allows you to change the name of your repository, but I might change it if they do.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
-erik
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
I just updated the expert tutorial page since the ET_2010_11 release will stay in svn. Wget will still suffice since the thornlist will checkout GetComponents using git, and place it in Cactus/bin.
Eric
Bruno C. Mundim mailto:bcmsma@astro.rit.edu December 28, 2010 11:34 AM
Hi Eric,
would you mind to update the wiki with the appropriate commands (git clone and path) for GetComponents?
Thanks, Bruno.
Eric Seidel mailto:eric@eseidel.org December 28, 2010 11:16 AM
I have applied this patch. Going forward, development of GetComponents will be done on GitHub.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 23, 2010 1:31 PM
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
Eric Seidel mailto:eric@eseidel.org December 23, 2010 1:25 PM
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 5, 2010 5:09 PM
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seideleric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
I added --no-check-certificate to wget in order to avoid error messages such as:
ERROR: certificate common name `*.github.com' doesn't match requested host name `github.com'. To connect to github.com insecurely, use `--no-check-certificate'. Unable to establish SSL connection.
Cheers, Bruno.
Eric Seidel wrote:
I just updated the expert tutorial page since the ET_2010_11 release will stay in svn. Wget will still suffice since the thornlist will checkout GetComponents using git, and place it in Cactus/bin.
Eric
Bruno C. Mundim mailto:bcmsma@astro.rit.edu December 28, 2010 11:34 AM
Hi Eric,
would you mind to update the wiki with the appropriate commands (git clone and path) for GetComponents?
Thanks, Bruno.
Eric Seidel mailto:eric@eseidel.org December 28, 2010 11:16 AM
I have applied this patch. Going forward, development of GetComponents will be done on GitHub.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 23, 2010 1:31 PM
Shouldn't the binary live directly in Cactus/bin/GetComponents? The CRL repository would live in repos, as usual, and the binary itself would be a symbolic link. We can then do the same with SimFactory.
-erik
Eric Seidel mailto:eric@eseidel.org December 23, 2010 1:25 PM
I made the necessary modifications to GetComponents in svn to support this. I have attached a modified patch to add the git version of GetComponents, which I would like to apply to finally complete the transition. GetComponents will now live at https://github.com/gridaphobe/CRL, and I will add a LaTeX version of the documentation shortly so that it can be built with the rest of the Cactus documentation.
The transition will be a two step process (assuming you are using the development version): the next time you update Cactus, you will get the updated thornlist and svn-GetComponents. Then when you run GetComponents again, it will add the git version, which will be located in Cactus/bin/CRL/GetComponents. This seems to be the most stable process to me.
Eric
Erik Schnetter mailto:schnetter@cct.lsu.edu December 5, 2010 5:09 PM
On Sat, Dec 4, 2010 at 12:26 PM, Eric Seidel eric@eseidel.org wrote:
Erik Schnetter wrote:
Ah, I think I misunderstood. I thought you wanted to have a link to the GetComponents script itself in the Cactus directory. Yes, a link to the CRL directory makes sense; this is the "standard" way we handle git repositories at the moment.
So I just looked into this, and it seems that GetComponents is not currently equipped to symlink an entire git repo. This is a silly oversight on my part; I can fix it, but that would require another patch to GetComponents. Another possibility would be to create the 'bin' directory and link GetComponents into bin. Then users could call './bin/GetComponents' or possibly './bin/CRL/GetComponents', the latter would allow for documentation to be linked as well.
I suggest to do both, to correct the fact that GetComponents cannot link whole repositories, and to create and use a "bin" directory in Cactus.
You could create a new project. Better now than later... "GetComponents" is a rather specific name and limits the scope of the project.
It is easier to just change the name of the project to CRL. This would change the URL to http://github.com/gridaphobe/CRL. If I do this it would probably make sense to change the URL on my website as well; however, I know that ET and possibly cactuscode.org link to my website. Are there any other pages that link to it?
I don't know. You can set up a permanent redirect on your web server, which will automatically forward people plus leave a log entry on your server telling you which pages to correct.
-erik
users@lists.einsteintoolkit.org
-
Bruno C. Mundim -
Eric Seidel -
Erik Schnetter -
Frank Loeffler