[attempting to regroup subthreads] [if short on time, please skim to the end to comment on the design]
* Martin Gagnon <[email protected]> [20120607 12:06]: > Le 2012-06-07 à 05:30, Joan Picanyol i Puig <[email protected]> a écrit : > > * Andrew Stuart <[email protected]> [20120531 16:15]: > >> There are source code files and also operating system configuration > >> files. > > > > I would keep two different repositories. For the second one, see below. > > > >> I use sudo to edit these files as most of the files are editable only > >> by root. [...] > > Needless to say, I'd encourage you to share your findings for the > > "fossil as a SCM for OS configuration" use case. > > For file from '/': look this thread: > > http://www.mail-archive.com/[email protected]/msg05576.html > > Fossil isn't usable from '/' dir. as a checkout. Some commands > sometimes work, most of them doesn't. So for system config. I end up > working on a checkout somewhere in a subdir in my home and I have a > script which copy file that have changed from '/' to my checkout. > ('fossil ls' is useful here) I did save your message from that thread, but ruby & meld are incompatible with my "minimal depencies" policy. Also, sudo does have its own issues and is not available in several scenarios. * Stephan Beal <[email protected]> [20120607 12:04]: > On Thu, Jun 7, 2012 at 11:30 AM, Joan Picanyol i Puig < > [email protected]> wrote: > > > * Andrew Stuart <[email protected]> [20120531 16:15]: > > > There are source code files and also operating system configuration > > > files. > > > > I would keep two different repositories. For the second one, see below. > > And i would go one step further and NOT use fossil for the system files. I would consider being able to use fossil for this a step further :) > Fossil does not support file permissions other than the +x bit But this can be just a missing feature, from http://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki : The optional 3rd argument defines any special access permissions associated with the file. The only special code currently defined is "x" which means that the file is executable. All files are always readable and writable. > and does not understand user/group ownership. Without that, using it > for managing system-level files is a disaster waiting to happen. If > certain files do not have exactly the right permissions... kaboom. pre-commit/post-update hooks could be used to work around this issue. See below regarding your "use tags for tracking permissions proposal". > The repo file itself needs to live somewhere outside of the "source tree." I'm not convinced this is true, in fact I believe I've had the repo at the root of the checkout some times. > Why not just do everything from the root dir? Chicken-egg - the repo > file will then live under the directory which it controls (this is > considered [by myself to be] bad practice). fossil will ignore the repo file if you don't add it. > Fossil is not the right tool for that job. I'd certainly like it to be. * Martin Gagnon <[email protected]> [20120607 12:32]: > may be storing the output of: ls -ln $(fossil ls) in the > repo could be used from a script to check/restore permissions... uids (or SIDs in Windows) might not be constant among diferents systems. I believe the uid<->uname mapping should be preserved on commit and require a command line override if it differs on checkout * Stephan Beal <[email protected]> [20120607 13:29]: > Permissions are a touchy subject because they're inherently > platform-specific and fossil tries to be platform-agnostic insofar as is > feasible. Once fossil has Unix permissions support, people will want > extended attributes support, ACLs, and other weird stuff (not that Unix > permissions aren't weird, but they are the most common case). I believe the (basic) Unix permission model can be easily supported in post-NT-Windows. * Stephan Beal <[email protected]> [20120607 13:38]: > i think tags (which are key/value pairs in fossil) could be used for > this if we would extend them to be able to tag arbitrary artifact > types (i seem to recall, possibly incorrectly, that we can only tag > commits right now?). e.g. tag unix-perms=0754. That could be a good idea, but the file format does not seem to be easily extended to support tagging "F"ile cards, since "T"ags are a card in the manifest as well. I believe it is much easier to extend de "F"ile card specification in a backward compatible way by specifying a 3 digit special code to mean "this permissions as defined by chmod()". Extend it still further to preserve uid<->login. qvb -- pica _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
