|
In connection to my problem with moving around sgclosets on a pen drive (see here) I was told the sgcloset stores an absolute path to the repos in descriptors.jsondb. AFAICS thats in "path_parent_dir", which is set to %SGCLOSET%/repo for any repo on any windows machine I've examined until now. Question: is there any special purpose for that variable, i.e. couldn't it be a relative path to the closet's location or couldn't it be omitted at all? As far as I can see it's pretty hard-coded into the sgcloset (or was it fs3?) class code. If I am right and there's no other use for that variable, it should be relatively straight forward to take the absolute path out of the descriptors and just calculate it on demand relative to the sgcloset's location. That would make it possible moving the whole closet around freely on one box or from box to box. |
|
I think you're right. path_parent_dir came into existence before it was possible to move .sgcloset with the SGCLOSET environment variable. Its continued existence makes it very difficult to move a closet after it's already got repositories in it, and it doesn't have an obvious useful purpose. We've had a bug logged for this since last May, but it hasn't gotten attention yet. It probably won't be addressed in time for the hosting release, but I've bumped its priority to get looked at shortly thereafter. Do you have some time estimation for when that feature will become available (in nightly builds and/or release)? No need to be precise, will it take more than, say, two months? I'd have to consider if for me it's worth the effort digging into the code and getting it out for myself or if I just wait until you fixed it.
(Jan 27 at 11:16)
Arne Mertz
1
got a design question on that: if path_parent_dir is removed completely without any substitute in the SG_repo struct, any repo will depend on having an existing closet to get its path. Currently there are some test cases (e.g. u0032_repo) where the path_parent_dir is set without any closet. So I see two possibilities: a) couple the repo tighter to the closet (and adjust the test cases) b) just not save the path_parent_dir in the descriptor, i.e. remove it before saving the descriptor and have it set (by the closet or manually) before creating/opening the repo. Which would you prefer?
(Jan 30 at 05:04)
Arne Mertz
Another possibility, which imho gives most flexibility: c) Make the path_parent_dir in the descriptor oprional. If FS3 is called to open/create a repo without that variable in the descriptor, look up the "default" path (i.e. ask the closet for it). That way, repo test cases can explicitly set the storage path while "normal" operations are not bound to a fixed closet/repo location.
(Feb 06 at 07:32)
Arne Mertz
|
|
I've written a little patch to get rid of the path_parent_dir, implementing possibility c) from my comments above: 1) The partial descriptor given by the closet does not contain the path_parent_dir any more. 2) On opening/creating repos, the FS3 repo implementation looks up if path_parent_dir is set and uses it, if found. Otherwise, $SGCLOSET/repo is used (same as in the partial descriptor before), but not stored in the descriptor. Making path_parent_dir optional instead of removing it completely allows the test suite to explicitly set storage locations for repos that don't have a closet. I have not (yet) written any additional tests, but some manual tests (moving the closet folder, setting SGCLOSET to the moved folder and opening the repo) succeeded. The diff, based on the sources released after SG's Veracity Build 1.6.0.4168, can be found on www.arne-mertz.de/veracity/path_parent_dir.diff |
