On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym
<ala...@snell-pym.org.uk>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/12/2011 07:10 PM, Joshua Paine wrote:
> > On 8/12/2011 1:50 PM, altufaltu wrote:
> >> 1. Versioned settings: I'd prefer having all settings in a single
> >> text file with name="value" kind of one-setting-per-line format
> >> (although I don't mind a value spanning multiple lines for
> >> readability) rather than one file per setting.
> >
> > I thought this at first, too, but one file per setting makes it easier
> > to manipulate with other tools, and it makes it easier to get an idea
> > what happened from the commit log.
>
> Aye. My "fossil extras > .fossil-settings/ignore_glob" brought a smile
> to my lips.
>

I'm at worst neutral on all the other changes. This one bothers me. I
consider fossil only having one file in the work space (__FOSSIL__) to be an
advantages, because it makes working with the tree using standard unix
commands that much easier. With most SCM software, I wind up doing some
tree-level command, seeing the SCM files in the output, cursing, and then
either running a SCM-provided command or a tweaked version of the unix
command that deals with the SCM files.

I can understand wanting versioned settings, but does it need to go into the
file system? Fossil versions other objects that aren't in the file system
(wiki, tickets, etc). Is there some reason the same can't be done for
versions?

If it has to be in the file system, I'd prefer one file to many. At the very
least, change the name of the directory to something that starts with
__FOSSIL__  to make it easier to tweak commands to deal with the names.

     <mike
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to