- changed status to open
- removed comment
GetComponents overwrites thorn list
Issue #323
closed
I specified a thorn list located in the main Cactus directory. GetComponents overwrote this thorn list with its own thorn list (the one it generates automatically).
Keyword:
Comments (19)
-
-
- removed comment
I don't like the /.crl location for a copy of a local thornlist, other than what GetComponents might use internally (and then of course /.crl is fine). And we should make clear what exactly happened. GetComponents doesn't need a copy if the thornlist was local. However, it can produce one when COMPONENTLIST_TARGET was specified within the thornlist. Was that the case for you Erik?
Assuming this was the case, we should indeed make sure that a) an existing target thornlist can be overwritten (that is what I use every time), but that at the same time b) it cannot be overwritten if it was one of the specified thornlists in the first place - that it cannot overwrite itself. It should be reasonably easy to check that the target is not one of the sources.
-
reporter
- removed comment
I used a very much shortened version of the ET manifest, containing only a single thorn. I don't believe there was a COMPONENTLIST_TARGET in there. I am also not too fond of the einsteintoolkit.th file generated in the main Cactus directory, but I can live with that.
If GetComponents wants to use this thorn list at a later time, then it needs to have a standard name. Keeping track of all checked out thorns makes a lot of sense, but this would need to be stored in the Cactus directory (not in home) and have a standard name. For example, .crl/ThornList or CRL/ThornList would be good candidates.
-
- removed comment
Keeping track of all checked out thorns within one Cactus source tree would either require to store multiple files (because you might mix several thornlists), or you have to combine those and then you can use a standard name. I don't think we have that combining code. Any such method would then miss thorns checked out by hand however. The only way to catch all of the thorns is the 'usual' way of searching the whole tree for the RCS-infos - which is messy and doesn't always work (in case someone really used a simple wget-http for a thorn).
-
- removed comment
Replying to [comment:4 knarf]:
Keeping track of all checked out thorns within one Cactus source tree would either require to store multiple files (because you might mix several thornlists), or you have to combine those and then you can use a standard name. I don't think we have that combining code. Any such method would then miss thorns checked out by hand however. The only way to catch all of the thorns is the 'usual' way of searching the whole tree for the RCS-infos - which is messy and doesn't always work (in case someone really used a simple wget-http for a thorn).
I actually have a script called generateCRL.py, which parses the RCS-info and generates a CRL file based on any repos found in your current directory. It only works for svn and cvs right now though (git, hg, and darcs are harder to handle due to the symlinks that we use). Back on topic though...
I don't really see why mixing several thornlists would cause problems. We already have support for handling multiple lists through the commandline, or the include mechanism that Frank added, so it seems to me that all we would have to do is add a couple lines of code to write $combined_components to $ROOT/.crl/current.crl or something (Erik, remember that GetComponents is agnostic to Cactus, so ThornList isn't really a good name). Then if GetComponents is run without a provided thornlist, it could check for the presence of this file, and proceed as normal.
Perhaps I'm overlooking something here, but it doesn't seem like it would cause problems, other than the case where a user decides to manually checkout a thorn. I'll try to experiment with it this weekend.
-
- removed comment
Ok, I've implemented what I suggested in my last post, and it's available in the experimental branch on !GitHub. I've tested it with my test.th list, the ET_2010_11 branch of ET, and the two combined, and I'm not getting any errors.
Please test the experimental version and let me know if you find any issues.
-
- removed comment
I tested the new version, and it writes the Cactus/.crl/component_list.crl fine. However, when then using another thornlist within the same directory, the new list doesn't get merged with that file, as I would have expected. Isn't this not what you proposed?
-
- removed comment
Not exactly. What I proposed was to store the most recent thornlist in `.crl/component_list.crl`. If you then used a different thornlist, `.crl/component_list.crl` would be overwritten. My plan would have been to call `GetComponents <ET_2010_11>`, then `GetComponents <ET_2010_11> <some_other_list>`, which would merge the two lists as you expected.
However, I think the behavior you expected makes much more sense. The only change I would make would be to add some flag like `--add <thornlist>`. Then you could do something like this:
GetComponents <ET_2010_11> cd Cactus GetComponents --add <extra_thorns>
-
- removed comment
I honestly wouldn't use the --add, because I would have to remember it every time or something gets overwritten. Could we just always merge them?
-
- removed comment
I guess that could work too. I was concerned about the case where you want to start using a new thornlist, but I think that GetComponents' current behavior regarding changing URL's kinda prohibits that. I'm not sure that's a good thing, but given that fact, your suggestion makes sense.
-
- removed comment
It seems this will actually be a bit more complicated than I thought, given the current structure of GetComponents. Unless the user passes the --root option, I don't know where the source tree is located. That means I won't know the value of $ROOT until some point during the parse_list subroutine, while I'm looping through the component lists. I'm pretty sure that Perl won't let me add to that list while looping through it, so I think I'll have to rework the parse_list subroutine a bit to finalize this change (it needs it anyway....)
I'm open to other suggestions though.
-
- changed milestone to ET_2011_05
- removed comment
-
- removed comment
The current version doesn't overwrite a thornlist anymore, is it? So, could we down-grade this ticket?
-
- marked as
- changed milestone to ET_2011_11
- removed comment
-
- removed comment
Eric: what is your opinion about this ticket?
-
- removed comment
Sorry, I haven't touched GetComponents at all over the summer... I'll make time to take another look at this ticket and the others in the next week or two :)
-
- removed milestone
- removed comment
Any progress on this? It is marked with a release milestone. Since the current version doesn't overwrite the thornlist I am removing the release milestone.
-
- changed status to resolved
- removed comment
-
- changed status to closed
- edited description
- Log in to comment
- Assignee
- Type
- Priority
- Status
- closed
- Component
- GetComponents
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 0
That's not good... I've been unhappy about the thornlist saving behavior in general too. I'd prefer something like the following:
1. `./GetComponents http://<et thornlist>` `=> ET downloaded to ./Cactus && thornlist stored in either $HOME/.crl/<et thornlist> or ./Cactus/.crl/<et thornlist>`
2. `cd Cactus && ./bin/GetComponents -u` `=> ET updated from saved thornlist in ./crl/<et thornlist>`
How does that sound? That should also allow you to provide your own customized thornlist to update from (although it shouldn't be necessary if you just check out ET using your custom thornlist)