On Sun, Aug 21, 2011 at 05:04:16PM -0700, Matt Welland wrote: > Hi Martin, > > I think fixing the bug of fossil having trouble running in / should be a > very low priority. It just seems like a bad idea to me in general to try to > run a scm out of / and spending time fixing bugs with respect to that > ability is not time well spent. But that is just my $0.02.
But I'm sure it's not intended to *don't* work on "/". If so, it is a bug and undefied behavior can occur. At least.. if it is not supported at all.. it should print a clear error message, but it would not make sens to me to have such limitation. And it was working before (I'll need to track from which version it stop working) I've update fossil a few time before I notice the problem. I've notice that on function "db_open_local()" it append a "." on beginning of g.zLocalRoot when the path of the database is "/". I guess it's a part of the problem. > > In case you are open to ideas on how other folks solve the problem of > keeping track of machine configurations attached is the script I now use for > that task. It is more complicated than your approach but I think more > flexible (Note that the script has only ever been used on Ubuntu, you should > not use the -rdel switch, and use at your own risk etc). To see what the > script does just do -dry. All very primitive but it works great for me. I > don't make any attempt to store permissions but it wouldn't be too hard to > add that feature if really needed. By using meld original permissions are > preserved. Look interesting, but may be overkill for what I want to do. It's only because we are like 3 admin that have root access and sometime.. it's good to have history of changes on some configuration files to understand why and when a change was made to a configuration. I don't even use that to restore the system. [snip] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
