Me too like fossil because of simplicity of one file / less file clutter. Why can't versionable settings be treated like a wiki or ticket page and versioned inside the repository itself rather than as a file in work area? Then we can also see changes done to [versioned] settings right there in timeline!
> ----- Original Message ----- > From: Mike Meyer > Sent: 08/15/11 07:46 AM > To: fossil-users@lists.fossil-scm.org > Subject: Re: [fossil-users] New features for merging > > On Sat, 13 Aug 2011 09:48:09 +0100 > Ben Summers <b...@fluffy.co.uk> wrote: > > On 12 Aug 2011, at 22:39, Mike Meyer wrote: > > > 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)? > > > > Settings aren't synced, which is the problem. When the values of the > > settings are stored in normal versioned files, they are, just as any other > > file. > > > > What I meant was that if you don't want to use this feature, you can still > > use settings in exactly the way you do in the current version. > > Yes, but my point is that my using setting exactly the way I do now > isn't sufficient to keep my workspace from getting cluttered by these > SCM files if someone turns them on in another clone of the > repository. Whether or not they're actually used is immaterial. > > Let me be crystal clear - I have absolutely no objection to the > features this change adds, and might well use them. My problem is with > the extra clutter in my workspace. Maybe I was spoiled by 7 years of > nothing but perforce (with *no* SCM files in the workspace) before > being exposed to svn in '05, but fossil having so little clutter is > one of it's attractions for me. > > > >> > 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 :-). > > OK, I wanted a "mechanism which works". And it doesn't add a new concept > > into fossil, it just uses files, which everyone understands. > > If you insist on them being files, then there's not much point in > further discussion. And having them in files means you can bring the > full power of unix to bear on them (which, of course, is why I want > them *out* of my workspace - as they are just noise when working with > *my* files), which is hard to argue with. > > But - any chance of moving them into the wiki? The fossil wiki command > would let you work with them with almost the same power at the command > line (i.e. - "fossil extras | fossil wiki import settings/ignore_glob" > should work), and in return you get to edit the settings via the wiki > gui. > > Thanks, > <mike > -- > Mike Meyer <m...@mired.org> http://www.mired.org/ > Independent Software developer/SCM consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
