Hi all,
I have a patch for GetComponents that I would like to apply to the svn trunk. It address the following trac tickets: #75 Checkout/update timestamp #61 make COMPONENTLIST_TARGET 'stable' #76 GetComponents should not create links if repository cannot be checked out
Ian mentioned that he thought the logs should be placed inside the checked out source tree, while GetComponents currently places them in $HOME/.crl/crl.log. I personally like the central location for logs, but I would be open to changing the location of the log files if others agree with Ian.
Any thoughts?
Eric
Hi,
On Wed, Nov 03, 2010 at 01:19:41PM -0400, Eric Seidel wrote:
I have a patch for GetComponents that I would like to apply to the svn trunk. It address the following trac tickets: #75 Checkout/update timestamp #61 make COMPONENTLIST_TARGET 'stable' #76 GetComponents should not create links if repository cannot be checked out
Are any of those patches so small that it is more or less obvious that they don't introduce new problems on some random machine?
If not, it would be nice to wait with those changes until the new version (which currently is being tested) is released. None of those tickets seem to be a real blocker for the release.
Ian mentioned that he thought the logs should be placed inside the checked out source tree, while GetComponents currently places them in $HOME/.crl/crl.log. I personally like the central location for logs, but I would be open to changing the location of the log files if others agree with Ian.
I agree with Ian that the source tree would be a more 'natural' place for those logs, at least in my way of thinking.
Frank
On Wed, Nov 03, 2010 at 01:19:41PM -0400, Eric Seidel wrote:
I have a patch for GetComponents that I would like to apply to the svn trunk. It address the following trac tickets: #75 Checkout/update timestamp #61 make COMPONENTLIST_TARGET 'stable' #76 GetComponents should not create links if repository cannot be checked out
Are any of those patches so small that it is more or less obvious that they don't introduce new problems on some random machine?
I would be surprised if any of those patches caused a new problem. The only one that actually affects the checkout/update behavior is #76, which only tells perl to move to the next component immediately after getting an error from "git/hg/darcs clone".
If not, it would be nice to wait with those changes until the new version (which currently is being tested) is released. None of those tickets seem to be a real blocker for the release.
Ian mentioned that he thought the logs should be placed inside the checked out source tree, while GetComponents currently places them in $HOME/.crl/crl.log. I personally like the central location for logs, but I would be open to changing the location of the log files if others agree with Ian.
I agree with Ian that the source tree would be a more 'natural' place for those logs, at least in my way of thinking.
Ok I can change it to place the logs in the source tree. Would you prefer they remain hidden, or should I store them as something like "GetComponents.log"?
Eric
Also, since you mentioned the release, would this be a good time to complete GetComponents' transition to GitHub? I haven't been pushing it since I have gotten quite busy with schoolwork.
Eric
On Wed, Nov 03, 2010 at 01:49:45PM -0400, Eric Seidel wrote:
Also, since you mentioned the release, would this be a good time to complete GetComponents' transition to GitHub? I haven't been pushing it since I have gotten quite busy with schoolwork.
I seem to remember some issues with github itself, and testing has already begun. I would like to release the current svn version, so we can try to use the github version for development.
Frank
On 3 Nov 2010, at 18:57, Frank Loeffler wrote:
On Wed, Nov 03, 2010 at 01:49:45PM -0400, Eric Seidel wrote:
Also, since you mentioned the release, would this be a good time to complete GetComponents' transition to GitHub? I haven't been pushing it since I have gotten quite busy with schoolwork.
I seem to remember some issues with github itself, and testing has already begun. I would like to release the current svn version, so we can try to use the github version for development.
I agree that we should not make such a change so close to a release. Unless any of the patches you talked about address serious problems, I would also hold off on those.
In future, will there be issues with keeping the web-accessible GetComponents script up-to-date automatically from the github repo?
I agree that we should not make such a change so close to a release. Unless any of the patches you talked about address serious problems, I would also hold off on those.
Ok that's fine, I'll wait until the release has been completed to apply the patches.
In future, will there be issues with keeping the web-accessible GetComponents script up-to-date automatically from the github repo?
No, GitHub supports post-commit hooks to take care of that. For example, I have a simple PHP script on my website that downloads the current version of GetComponents when it is pinged by GitHub. The current master version will always be available at https://github.com/gridaphobe/GetComponents/raw/master/GetComponents as well.
Eric
users@lists.einsteintoolkit.org