Re: [fossil-users] New features for merging
On 15 Aug 2011, at 21:42, Matt Welland wrote: > 2011/8/15 Lluís Batlle i Rossell >> 3) The file interface offers most version capabilities currently, in fossil. >> Easier to reach old version, allowing branching, branches of code may need >> different settings (ignore glob?). >> > I have had this need many times. For example a build directory that must be > ignored is moved. If I branch from the previous state and the ignores reflect > the new state I now have irrelevant junk cluttering up my "fossil status". > Hardly the end of the world but really a completely unnecessary annoyance. > > I am very much looking forward to this mechanism being a part of the official > build. It's been merged into trunk, so should be in the next release. I've certainly found it makes a big difference. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
2011/8/15 Lluís Batlle i Rossell > On Mon, Aug 15, 2011 at 02:41:48AM +, altufa...@mail.com wrote: > > 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! > > Thinking of reasons... > 1) You may not want versioned settings, and keep with one file. > 2) The map to files is quite easy to use. Some people use, then, '.wiki' > files > in the repository instead of the usual wiki pages. > 3) The file interface offers most version capabilities currently, in > fossil. > Easier to reach old version, allowing branching, branches of code may need > different settings (ignore glob?). > I have had this need many times. For example a build directory that must be ignored is moved. If I branch from the previous state and the ignores reflect the new state I now have irrelevant junk cluttering up my "fossil status". Hardly the end of the world but really a completely unnecessary annoyance. I am very much looking forward to this mechanism being a part of the official build. > 4) The versioned settings in files are *implemented* now. Having them ready > in > trunk should not annoy anyone who does not want to use them (if they > control the > repositories). > ___ > 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
Re: [fossil-users] New features for merging
On Mon, Aug 15, 2011 at 10:49 AM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > On Sun, 14 Aug 2011 19:16:50 -0700 > Mike Meyer wrote: > > [...] > > 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. > This is a rather beautiful idea but I always thought that wiki in > fossil is not really versioned and it is also repository-wide (hence > you woun't be able to have different ignore settings on different > branches). Please correct me if I'm wrong. But if I'm not, the idea of > using wiki for this kind of job won't work. > Half right. Wiki pages are versioned, and you can use the UI to go looking through the older versions, etc. The version of fossil I have here (downloaded windows binary) doesn't have the ability to deal with wiki pages by version from the command line, thought it's listed as a TODO. Their doesn't appear to be any way to branch them, though. So yes, like the current version settings, you couldn't have different settings for different branches. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Sun, 14 Aug 2011 19:16:50 -0700 Mike Meyer wrote: [...] > 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. This is a rather beautiful idea but I always thought that wiki in fossil is not really versioned and it is also repository-wide (hence you woun't be able to have different ignore settings on different branches). Please correct me if I'm wrong. But if I'm not, the idea of using wiki for this kind of job won't work. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Mon, Aug 15, 2011 at 02:41:48AM +, altufa...@mail.com wrote: > 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! Thinking of reasons... 1) You may not want versioned settings, and keep with one file. 2) The map to files is quite easy to use. Some people use, then, '.wiki' files in the repository instead of the usual wiki pages. 3) The file interface offers most version capabilities currently, in fossil. Easier to reach old version, allowing branching, branches of code may need different settings (ignore glob?). 4) The versioned settings in files are *implemented* now. Having them ready in trunk should not annoy anyone who does not want to use them (if they control the repositories). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
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 wrote: > > On 12 Aug 2011, at 22:39, Mike Meyer wrote: > > > On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers wrote: > > >> On 12 Aug 2011, at 20:44, Mike Meyer wrote: > > >> > On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym > > >> 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
Re: [fossil-users] New features for merging
On Sat, 13 Aug 2011 09:48:09 +0100 Ben Summers wrote: > On 12 Aug 2011, at 22:39, Mike Meyer wrote: > > On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers wrote: > >> On 12 Aug 2011, at 20:44, Mike Meyer wrote: > >> > On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym > >> 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, 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
Re: [fossil-users] New features for merging
On 12 Aug 2011, at 22:39, Mike Meyer wrote: > On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers wrote: >> On 12 Aug 2011, at 20:44, Mike Meyer wrote: >> > On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym >> 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. > >> > 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 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. I too like the idea of using .fossil instead, falling back to _FOSSIL_ and .fos for backwards compatibility. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 2:44 PM, Stephan Beal wrote: > On Fri, Aug 12, 2011 at 11:39 PM, Mike Meyer wrote: > >> space. But we already have __FOSSIL__, so (in the words of Arlo Guthrie) >> one big pile is better than two little piles. >> > > For the benefit of those born after Star Wars: > > http://www.arlo.net/resources/lyrics/alices.shtml > Which will make http://www.ai.sri.com/~delacaze/alu-site/alu/humor/alices-lispm.html a lot funnier. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 11:39 PM, Mike Meyer wrote: > space. But we already have __FOSSIL__, so (in the words of Arlo Guthrie) > one big pile is better than two little piles. > For the benefit of those born after Star Wars: http://www.arlo.net/resources/lyrics/alices.shtml http://www.youtube.com/watch?v=5_7C0QGkiVo -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Aug 12, 2011, at 22:28 , Ben Summers wrote: >> 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_. Most notably shell's glob ignores dotfiles, what makes them mostly a non-issue for me... And I find the _FOSSIL_ string particularly disturbing on listings. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On 12 Aug 2011, at 20:44, Mike Meyer wrote: > On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym > 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*. > > 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 found svn's properties a bit annoying to deal with, as they're not as visible as files and can be a little fiddly to deal with. Putting the settings in a single top level directory also removes the need to scatter SCM files throughout the tree, as you would with .gitignore files. > > 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_. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
-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. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Ff/QACgkQRgz/WHNxCGol5wCfeL2HcMT8J+/hvY0/0ljyFydW Q/cAn3aPay3VfvoQLZnK/p1iidTEfaBD =oPGM -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 01:35:33PM -0400, Joshua Paine wrote: > It's not hard to turn the new output into what you want, though. E.g.: > > fossil extras | grep -v '..' You are missing an important thing here. "fossil extra" has to traverse the directory tree, which can be a huge problem. I am talking about a *cached* run time of multiple seconds here. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
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. > I haven't tested your branch but would like to know if following > would work: fossil commit -m "comment" ../parent.file > ../parent/child.file local.file sub/file.name ... also for other > commands like rm, add, etc. This already works, so I would certainly expect it to keep working! -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
Ben, Thanks for providing improvements in fossil. I'd like to share 2 comments: 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. 2. Like many other users commented, I'd alo like relative path setting to be ON by default. I haven't tested your branch but would like to know if following would work: fossil commit -m "comment" ../parent.file ../parent/child.file local.file sub/file.name ... also for other commands like rm, add, etc. - Altu > - Original Message - > From: Ben Summers > Sent: 08/12/11 04:17 PM > To: fossil-users@lists.fossil-scm.org > Subject: [fossil-users] New features for merging > > Richard has kindly indicated he is probably willing to merge the changes in > the ben-testing branch if the community has no objections, after being asked > for any suggestions on improvements. > > I'd particularly like input on how these should be documented, and the names > chosen for settings and command line options. > > I've added: > > > * Versionable settings > > The inconvenience of using ignore-glob came up again a few days ago. When I > started using fossil, I couldn't quite work out how to use them sensibly. So, > I implemented "versionable" settings which take the values from versioned > files in the repository. For ignore-glob, it gives you the rough equivalent > of .gitignore files, although they're only specified at the root of the > repository in a .fossil-settings directory. > > Documentation: > - fossil help settings > - Settings page in the web UI > - http://fossil-scm.org/index.html/doc/ben-testing/www/settings.wiki > (linked from home page) > > > * SSL improvements > > I added support for SSL client certificates, for an extra level of > authentication to the server. In addition, I added a setting to specify the > trusted SSL root certificates. > > After implementing this, I was told of the existing jan-clientcert branch, > and feel a bit silly for not noticing it earlier. This implementation, > however, is much simpler and uses facilities built in to OpenSSL instead of > doing certificate management inside fossil. As such, the impact on the fossil > code is much less, but does require external programs to do the certificate > management. With those external programs, it can do everything that the > jan-clientcert branch does. > > Documentation: > - fossil help settings (ssl-identity, ssl-ca-location) > - fossil help clone (--ssl-identity option) > - error message when trying to clone a repo which requires a client cert > - http://fossil-scm.org/index.html/doc/ben-testing/www/ssl.wiki > (linked from home page and existing server instructions page) > > > * Relative pathname listings > > One of my projects requires that I work with the current working directory > inside a subdirectory of the repository. I found it a bit confusing to list > all filenames relative to the root of the repository, especially when copying > and pasting output of 'extras' to 'add'. > > I've added a "relative-paths" setting. This defaults to 'off', to avoid > changing the output for existing projects. Set this 'on' to list pathnames > relative to the current working directory for status, changes and extras > commands, with output similar to git's listings. > > You can also override this setting on the command line with the --rel-paths > and --abs-paths options. > > Documentation: > - fossil help settings (relative-paths) > - fossil help status / changes / extras (--rel-paths & --abs-paths options) > > Discussion on mailing list: > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05066.html > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05072.html > (although options etc have changed at Richard's suggestion) > > > * empty-dirs setting > > I moved to fossil from subversion, and my project expected the ability to > version empty directories. I think this has come up a couple of times on the > list. > > In an ideal world, I'd add the ability to version directories 'properly', but > it would be quite a large change to the internals. Taking a pragmatic > approach, I added a versionable empty-dirs setting which allows you to > specify a list of directories which should exist after a checkout. > > Documentation: > - fossil help settings > > > Thanks for any feedback. > > Ben > > > > -- > http://bens.me.uk/ > > > > ___ > 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
Re: [fossil-users] New features for merging
On 8/12/2011 1:09 PM, Joerg Sonnenberger wrote: >> * Relative pathname listings > > Not something I agree with. I think you want to implement the git > behavior? I find that utterly confusing and it doesn't add any real > value. It's tremendously useful for, e.g., my fossil_php_lint script that I use to run `php -l` on all modified or added PHP files before I commit. It means you can pipe (or xargs) the output of any of the affected commands to other processes no matter where you are in the repo and have it actually work. > From dealing with large repositories, it makes a lot more sense > to follow CVS/SVN here and restrict the operation to the directory > currently in and have an option to make it default to the whole tree. fossil is more like git in expected repo layout than it is like SVN. In SVN you *have* to treat everything as directory-relative, since branches and tags are also modeled as directories. I think we're past the point in history where taking design cues from CVS looks like a good idea on the face. It's not hard to turn the new output into what you want, though. E.g.: fossil extras | grep -v '..' -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Aug 12, 2011, at 12:47 , Ben Summers wrote: > > I've added: > > > * Versionable settings > * SSL improvements > * Relative pathname listings > * empty-dirs setting I'm for the merge in general. I'd argue that relative pathnames could be turned on by default. It's quite hard to imagine anything breaking because of that... Pozdrawiam, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 11:47:22AM +0100, Ben Summers wrote: > * Versionable settings OK. > * SSL improvements OK > * Relative pathname listings Not something I agree with. I think you want to implement the git behavior? I find that utterly confusing and it doesn't add any real value. From dealing with large repositories, it makes a lot more sense to follow CVS/SVN here and restrict the operation to the directory currently in and have an option to make it default to the whole tree. > * empty-dirs setting Not sure if I agree with the implementation, but I know about the problem. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 5:01 PM, Ben Summers wrote: > Richard is rightly very conservative about changes to Fossil, and asked it > was off by default. I understand his reluctance to risk breaking anything, > however remote the chance. > While i sympathize with Richard's position on this as a general policy, i think the current behaviour is not something someone has been relying on (or they have had to invest significant script-fu to work around it, as opposed to _with_ it). This is one of those cases which reminds me of a long time ago... i patched a bug in Jakarta Ant and the devs refused it because someone might be relying on the old bug. The bug, in that case, was a NullPointerException which invariably killed the build, so nobody could have possibly been relying on it. i feel the same way about the "absolute" paths (though obviously they're not fatal, i feel they were the wrong behaviour from the start). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On 12 Aug 2011, at 16:10, Alaric Snell-Pym wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/12/2011 04:04 PM, Ben Summers wrote: >> >> On 12 Aug 2011, at 15:54, Alaric Snell-Pym wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 08/12/2011 11:47 AM, Ben Summers wrote: Richard has kindly indicated he is probably willing to merge the changes in the ben-testing branch if the community has no objections, after being asked for any suggestions on improvements. >>> >>> The features look useful, in my opinion; I'll try building your branch >>> and playing with them personally to see about all those usage messages >>> and the like! >> >> I have tried to make it as self-documenting as possible, especially the SSL >> client certificates. >> >> Thanks for giving it a go! >> > > Having just built fossil (so having a lot of tedious extras), it was > very satisfying to say: > > fossil extras > .fossil-settings/ignore-glob You might want to tidy that up with globs to be a bit faster, as Fossil internally generates some SQL which contains every pattern you give it in one big expression. So use bld/* and so on. Not that SQLite is in any way slow. But yes, it's nicer this way. :-) > > And the relative paths thing is, indeed, much nicer than the default. I am finding I am making a lot less operator error with it like this. I'd never get the add or revert commands right before. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 04:04 PM, Ben Summers wrote: > > On 12 Aug 2011, at 15:54, Alaric Snell-Pym wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 08/12/2011 11:47 AM, Ben Summers wrote: >>> >>> Richard has kindly indicated he is probably willing to merge the changes in >>> the ben-testing branch if the community has no objections, after being >>> asked for any suggestions on improvements. >>> >> >> The features look useful, in my opinion; I'll try building your branch >> and playing with them personally to see about all those usage messages >> and the like! > > I have tried to make it as self-documenting as possible, especially the SSL > client certificates. > > Thanks for giving it a go! > Having just built fossil (so having a lot of tedious extras), it was very satisfying to say: fossil extras > .fossil-settings/ignore-glob And the relative paths thing is, indeed, much nicer than the default. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5FQlQACgkQRgz/WHNxCGowxwCfXsZgBDa8PxiflJqptIRFPSgQ IvUAn3c0kbJUk4hnLTNKIR8xvr7ZMwOc =x9sL -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On 12 Aug 2011, at 15:54, Alaric Snell-Pym wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/12/2011 11:47 AM, Ben Summers wrote: >> >> Richard has kindly indicated he is probably willing to merge the changes in >> the ben-testing branch if the community has no objections, after being asked >> for any suggestions on improvements. >> > > The features look useful, in my opinion; I'll try building your branch > and playing with them personally to see about all those usage messages > and the like! I have tried to make it as self-documenting as possible, especially the SSL client certificates. Thanks for giving it a go! > The empty dirs one is a bit of a hack, though; would it be > a good idea to merge in everything *but that* for now? And there I was hoping to avoid having to maintain a branch. > > Indeed, does it need to be part of Fossil - one could just have an > empty-dirs file and a script you run after checkout (dare I say "hook"? > Nah, best not...) that ensures they all exist? I'd argue that the state of the tree was Fossil's responsibility. Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On 12 Aug 2011, at 15:46, Joshua Paine wrote: > On 8/12/2011 6:47 AM, Ben Summers wrote: >> * Versionable settings > > +1 This looks like a good way to do this Thank you! :-) > >> * Relative pathname listings > > I would really like to see this on by default. It's the right way, and > the sooner we fix it, the better. I expect tool impact would be minimal > since running all commands from the repo root is the only sensible way > to make use of the existing output, and output from the repo root is > unchanged, right? Correct. If you run it from the root you'll see identical output to the current version. Richard is rightly very conservative about changes to Fossil, and asked it was off by default. I understand his reluctance to risk breaking anything, however remote the chance. > >> * empty-dirs setting > > This is the only one I don't like. I don't hate it, but it feels like an > odd hack. If it were to be implemented "properly", there'd be more code in the core to handle directories as another case, and impact to all the commands like add, delete, changes, and so on. This is fairly low impact, and allows fossil to retain the purity of design which focuses only on files, while still giving those who need this a way of getting what they need (or want?). Empty directory support has come up a few times on the list. That said, I agree with your description of it as an "odd hack". Ben -- http://bens.me.uk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 11:47 AM, Ben Summers wrote: > > Richard has kindly indicated he is probably willing to merge the changes in > the ben-testing branch if the community has no objections, after being asked > for any suggestions on improvements. > The features look useful, in my opinion; I'll try building your branch and playing with them personally to see about all those usage messages and the like! The empty dirs one is a bit of a hack, though; would it be a good idea to merge in everything *but that* for now? Indeed, does it need to be part of Fossil - one could just have an empty-dirs file and a script you run after checkout (dare I say "hook"? Nah, best not...) that ensures they all exist? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5FPp8ACgkQRgz/WHNxCGopeACdGhIRMgTAD5pGOMDoUxvvo1gv WAEAoIy5yZ+yiwA1YSBNAJ8Ye7TnVxq/ =ESze -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On 8/12/2011 6:47 AM, Ben Summers wrote: > * Versionable settings +1 This looks like a good way to do this > * SSL improvements I have no use for this at the moment myself, but it looks good. I think it's reasonable to expect people who want to use certs to already have the tools for it. > * Relative pathname listings I would really like to see this on by default. It's the right way, and the sooner we fix it, the better. I expect tool impact would be minimal since running all commands from the repo root is the only sensible way to make use of the existing output, and output from the repo root is unchanged, right? > * empty-dirs setting This is the only one I don't like. I don't hate it, but it feels like an odd hack. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 11:47:22AM +0100, Ben Summers wrote: > > Richard has kindly indicated he is probably willing to merge the changes in > the ben-testing branch if the community has no objections, after being asked > for any suggestions on improvements. In very short, I favour the merge. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 12:47 PM, Ben Summers wrote: > * Versionable settings > :) > * SSL improvements > :| (No opinion.) > * Relative pathname listings > :-D (i can't count how often the current behaviour has gotten on my nerves) > * empty-dirs setting > ...In an ideal world, I'd add the ability to version directories > 'properly', but it would be quite a large change to the internals. Taking a > pragmatic approach, I added a versionable empty-dirs setting which allows > you to specify a list of directories which should exist after a checkout. i've got no opinion for this one. IMO it's simpler just to put a 0-byte dummy file in the dir (and old hack used by many CVS repos). > Thanks for any feedback. > Thanks for the code :). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
