Hi, Thanks for the discussion, it looks that there's some interest in it. For the record, I'm currently using mercurial + mtree, but I'd like to avoid the dependency on Python & FreeBSD.
* Stephan Beal <sgb...@googlemail.com> [20110525 17:25]: > > System-level config files often need to belong to a specific user and/or > group. So fossil would also have to track user names, and there is no > guaranty that user 'stephan' on host1 is actually the same user as 'stephan' > on host2 (though they tend to be the same person on my systems ;). > Philosophically, i don't think that problem can be solved generically. It is certainly not easy (think LDAP/AD deployments), but fossil is missing another crucial feature: pre/post-commit hooks. > Even if fossil did support storing/restoring the whole permissions (with > user/group names/IDs), it literally couldn't work for anyone but the root > user: Unix systems won't let a user's process chown a file to a different > user. Obviously the OS user running fossil needs apropriate permissions. Given that though, and assuming fossil grows the ability to track them, there's no reason why it should not be able to restore them. > And what to do on files imported into fossil from Windows and checked out on > Unix systems? Regarding ownership, I believe the best that can be done is store a id/name pair on chekin and warn if the mapping does not resolve the same on checkout. * Stephan Beal <sgb...@googlemail.com> [20110525 19:28]: > On Wed, May 25, 2011 at 7:35 PM, Bill Burdick <bill.burd...@gmail.com>wrote: > > > Etckeeper is a specialized tool that uses DVCSes for versioning. It's OK > > that Fossil can't support everything needed for this, but I don't think it's > > unreasonable for Joan to ask whether Fossil can be used for it -- every > > major DVCS can, except for Fossil. > > My apologies - it wasn't my intention to imply that it's not a reasonable > usage/feature, i was just pointing out reasons it won't work well out of the > box, and why supporting such usage probably requires more effort than it > would seem to on the surface. The problem is that fossil does not support neither "good-enough" ownership/permission tracking nor the flexibility to work around it before/after commit. I hope that fossil grows either (or both :) of these features some time, even though they are likely not one-liners. qvb -- pica _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
