On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers <b...@fluffy.co.uk> wrote:
> On 12 Aug 2011, at 20:44, Mike Meyer wrote:
> > 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.
>
> You can ignore this new feature, and everything will continue to work as it
> did before. The slightly clumsy name of "versionable" is to imply that they
> *can* be versioned, not that they inherently *are*.
>
So these won't get copied around by push, pull, clone or sync? If they do,
is there at least an easy way to turn them back into regular settings so I
can delete them (and thus start the commit wars)?
> 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?
> It would need to be part of checkin somehow, as wiki pages, tickets, etc,
> aren't in a branch. This would be adding another mechanism, when the whole
> point of this new feature is to give the option to move away from using an
> additional mechanism for these settings.
>
I thought the whole point was to provide versioned settings? If all you want
is not to have an additional mechanism, then just don't merge this feature
into the trunk :-).
> 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.
> More tools hide names beginning with a dot than they do _FOSSIL_.
>
Having to keep track of which tools need to deal with both and which only
need to deal with one makes things worse, not better. If we didn't already
have __FOSSIL__, it'd be a win, as it would mean some tools would work right
even if you forgot to deal with the SCM turds in the work space. But we
already have __FOSSIL__, so (in the words of Arlo Guthrie) one big pile is
better than two little piles.
<mike
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
