#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by eric9):

* status: new => accepted

Comment:

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)

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by eschnett):

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.

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by eric9):

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.

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by knarf):

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?

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by knarf):

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?

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by eric9):

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.

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: critical | Milestone: ET_2011_05 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by knarf):

The current version doesn't overwrite a thornlist anymore, is it? So, could we down-grade this ticket?

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: minor | Milestone: ET_2011_11 Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+-----------------------------------------------

Comment (by knarf):

Eric: what is your opinion about this ticket?

#323: GetComponents overwrites thorn list ----------------------------+----------------------------------------------- Reporter: eschnett | Owner: eric9 Type: defect | Status: accepted Priority: minor | Milestone: Component: GetComponents | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by hinder):

* milestone: ET_2011_10 =>

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.