#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.