Re: [fossil-users] Creating repositories remotely
On Thu, Aug 11, 2011 at 02:20:34PM -0700, Mike Meyer wrote: On Thu, Aug 11, 2011 at 2:03 PM, Stephan Beal sgb...@googlemail.com wrote: There is no built-in way to create a remote repository (a fossil server represents the _one_ repository which must already exist before the server can start). You have to create the .fsl file, run fossil ui once to set the admin password, upload it to the server, and either run it (if you're running it as a server) or set up a CGI script wrapper to run it (for CGI use). How much damage would setting up one .fsl file, and then copying it multiple times - once for each new repository - cause? If that worked, you could wrap a script around scp (or pscp on Windows) to make a create remote repository command. I'm not at all resistant to using ssh, but on some servers, particularly on a number of shared hosts out there, all kinds of shell are disabled, including ssh, so that wouldn't work. With cgi, you could have a global ui allowing the creation of a new repository, but I understand the argument stated in this thread that this is not desirable for cross-compatibility. ___ 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] Creating repositories remotely
On Thu, Aug 11, 2011 at 05:24:06PM -0400, Richard Hipp wrote: On Thu, Aug 11, 2011 at 5:21 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Aug 11, 2011 at 4:53 PM, lists li...@devilray.eu wrote: I'm a new user of fossil, having come grudgingly from CVS. Needless to say, my stubbornness was unfounded-life is immeasurably easier than it was on CVS for hundreds of little (and big) reasons. In trying to convert my workflow to fossil, I haven't been able to find any information in the wiki nor mail archives about creating a new repository, remotely, on the fossil server. For a server you need two things: (1) The repository database file (the *.fossil file) and (2) some mechanism to serve that file. Item (2) can be either CGI, or inetd/xinetd, or fossil server. See the documentation for details. In any of these cases you have to give it the name of a repository database file to serve. But here is a cool feature: The name of the repo database file you give to Fossil for (2) can actually be a directory rather than an individual file. In that case, Fossil will serve all repos underneath that directory. An amplification: In order for this to work, the repository files need to be named with a .fossil suffix. Other suffixes like .fsl or .f or anything else. If you are dealing with individual repositories, the suffix does not matter - it can be anything you want. But for this one server-every-file-in-a-subdirectory feature, all the repositories files have to end with .fossil. Suppose you have (2) set up to serve files out of the /home/www/repos directory on your server. Then in order to create a new repository on the server you can do this: (a) Create the repository locally using fossil init repo-name.fossil (b) Do whatever check-ins and configuration you want on the new repository, including setting the administrator password. (c) Test your setup locally using fossil ui (d) Scp or ftp the repository file into the /home/www/repos directory on the server. If you upload a repo file named /home/www/repos/abc.fossil then you can access it using http://domain/abc. If you upload the file to /home/www/repos/dir1/dir2/xyz.fossil, then you access it using http://domain/dir1/dir2/xyz. And so forth. So once you get (1) up and going, installing a new repository is just a matter of uploading a new repository file. Thank you, I read through all the documentation you've got on the site, and understood eventually how to create a multiple repository, and have got one up and running nicely. I was merely hopeful that I could create repositories without resorting to ssh. Whereas I am happy to use ssh to upload to my own central vcs server, this becomes non-trivial for a) general users (non-developers) b) those with limited hosting accounts It's not exactly a big deal, just nice functionality. Sacha ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Concepts: why close a lead
I am trying to get my head around some basic concepts. One question that pops up: why/when would I close a leaf. Is this purely for myself to remember I have finished that part of branch or are there more questions and/or reasons? Jos ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SQLITE_BUSY: statement aborts at 2: [ROLLBACK]
(sorry about my other message ending up in another thread, was not meant that way) While playing for the first time with Fossil (open, close, delete etc.) I ended up with the message: C:\Windows\fossil.exe: no such file: d:/test/source/monkey.txt C:\Windows\fossil.exe: SQLITE_BUSY: statement aborts at 2: [ROLLBACK] cannot rollback transaction - SQL statements in progress I am just messing around but maybe this SQL-error is a sign of another underlying problem worth investigating? The best part: I can easily reproduce it: - Create an empty folder 'test' - Create a Windows batchfile with the following content and run it: :: Place this batchfile in an empty directory and start it. del monkey.fossil del source\_FOSSIL_ del source\monkey.txt fossil init monkey.fossil mkdir source cd source echo Hello worldmonkey.txt fossil open ../monkey.fossil fossil add monkey.txt del monkey.txt echo Y|fossil commit -m Versie 2010 --tag v2010 --branch v2010 cd .. :: End of batchfile This ends with: C:\Windows\fossil.exe: no such file: d:/test/source/monkey.txt C:\Windows\fossil.exe: SQLITE_BUSY: statement aborts at 2: [ROLLBACK] cannot rollback transaction - SQL statements in progress This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC I have no clue what is wrong (was also directly e-mailed to Richard while access to this group was not yet working for me but he is busy :-) ___ 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] SQLITE_BUSY: statement aborts at 2: [ROLLBACK]
On Fri, Aug 12, 2011 at 10:36:13AM +0200, Jos Groot Lipman wrote: fossil open ../monkey.fossil fossil add monkey.txt del monkey.txt echo Y|fossil commit -m Versie 2010 --tag v2010 --branch v2010 What do you intend to do with this? Maybe you should run fossil rm monkey.txt after the del? fossil cannot find the file you told it to add. ___ 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] SunOS 5.1 build?
On Thu, Aug 11, 2011 at 09:49:15PM -0400, Tomek Kott wrote: Hi folks, A request for those who are configure / make wizards: could someone provide me with a build of fossil from SunOS / sparcv9? Specifically 5.1. I don't have ssh access to the server, so I can't compile it myself. At least, I don't know enough about compiling to do so myself on my cygwin install. Does someone have a fairly recent build handy that they could send my way? For cygwin: unpack the source tarball. chdir into the directory, and run make. You will need installed in cygwin, I think: gnu make, gcc, openssl-dev. ___ 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] SunOS 5.1 build?
You mean SunOS 5.1? which is Solaris 2.1? 2011/8/12 Tomek Kott tkott.s...@gmail.com: Hi folks, A request for those who are configure / make wizards: could someone provide me with a build of fossil from SunOS / sparcv9? Specifically 5.1. I don't have ssh access to the server, so I can't compile it myself. At least, I don't know enough about compiling to do so myself on my cygwin install. Does someone have a fairly recent build handy that they could send my way? Thanks, Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Alexander Vladimirov idkfa at idkfa dot org dot ru ___ 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] SQLITE_BUSY: statement aborts at 2: [ROLLBACK]
Sorry, I agree it does not make sense what I trying. The Fossil message that it cannot find the file is perfect. Committing is Fossil is transactional so the entire commit should be rolled back. So far so good but the SQL-message worries me: Cannot rollback transaction I wonder I the transaction was indeed rolled back. -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Lluís Batlle i Rossell Sent: vrijdag 12 augustus 2011 11:02 To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] SQLITE_BUSY: statement aborts at 2: [ROLLBACK] On Fri, Aug 12, 2011 at 10:36:13AM +0200, Jos Groot Lipman wrote: fossil open ../monkey.fossil fossil add monkey.txt del monkey.txt echo Y|fossil commit -m Versie 2010 --tag v2010 --branch v2010 What do you intend to do with this? Maybe you should run fossil rm monkey.txt after the del? fossil cannot find the file you told it to add. ___ 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
[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
Re: [fossil-users] Concepts: why close a lead
On Fri, Aug 12, 2011 at 10:26 AM, Jos Groot Lipman donts...@home.nl wrote: One question that pops up: why/when would I close a leaf. Is this purely for myself to remember I have finished that part of branch or are there more questions and/or reasons? The only reason i've ever done it is to avoid confusion on the Leaves page. People not familiar with fossil have sometimes asked me, which link do i need to download? so i try to keep only one leaf open at a time when possible. -- - 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] SunOS 5.1 build?
@Alexander, On Fri, Aug 12, 2011 at 5:16 AM, Alexander Vladimirov id...@idkfa.org.ruwrote: You mean SunOS 5.1? which is Solaris 2.1? I honestly don't know if that is Solaris 2.1. I do know it is SunOS 5.1 running on a sparc cpu. It's not my server, and all I know is from a ColdFusion server variable. I tried a linux build of x86, but that's throwing an error, so I think it's because of the sparc architecture. @Lluis, For cygwin: unpack the source tarball. chdir into the directory, and run make. You will need installed in cygwin, I think: gnu make, gcc, openssl-dev. Sorry, I wasn't clear. I have cygwin, make gcc, etc. installed, but I don't know how to *cross*-compile from my x64 / x86 machines for a sparc / sunOS architecture. I'm afraid tar -xzf ***, cd ***, configure, make is about all I know of compiling from source. If I understood a previous discussion surrounding a new 'autoconf / automake / auto-something' then I should be able to do it, I just don't know how. Thanks, Tomek ___ 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] SunOS 5.1 build?
On Fri, Aug 12, 2011 at 11:16 AM, Alexander Vladimirov id...@idkfa.org.ruwrote: You mean SunOS 5.1? which is Solaris 2.1? Yes, that's 2.1: http://en.wikipedia.org/wiki/Solaris_(operating_system) Released in 1992, with an end of support date of 1999. -- - 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] SQLITE_BUSY: statement aborts at 2: [ROLLBACK]
On Fri, Aug 12, 2011 at 5:23 AM, Jos Groot Lipman donts...@home.nl wrote: Sorry, I agree it does not make sense what I trying. The Fossil message that it cannot find the file is perfect. Committing is Fossil is transactional so the entire commit should be rolled back. So far so good but the SQL-message worries me: Cannot rollback transaction I wonder I the transaction was indeed rolled back. The transaction is rolled back the next time the repository is accessed. So no harm done. The change at http://www.fossil-scm.org/fossil/ci/9515143de5 causes Fossil to be more aggressive about rolling back transactions following an error like this, so that the warning does not come up any more. -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Lluís Batlle i Rossell Sent: vrijdag 12 augustus 2011 11:02 To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] SQLITE_BUSY: statement aborts at 2: [ROLLBACK] On Fri, Aug 12, 2011 at 10:36:13AM +0200, Jos Groot Lipman wrote: fossil open ../monkey.fossil fossil add monkey.txt del monkey.txt echo Y|fossil commit -m Versie 2010 --tag v2010 --branch v2010 What do you intend to do with this? Maybe you should run fossil rm monkey.txt after the del? fossil cannot find the file you told it to add. ___ 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 -- D. Richard Hipp d...@sqlite.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] SunOS 5.1 build?
On Fri, Aug 12, 2011 at 1:56 PM, Tomek Kott tkott.s...@gmail.com wrote: Sorry, I wasn't clear. I have cygwin, make gcc, etc. installed, but I don't know how to *cross*-compile from my x64 / x86 machines for a sparc / sunOS architecture. I'm afraid tar -xzf ***, cd ***, configure, make is about all I know of compiling from source. If I understood a previous discussion surrounding a new 'autoconf / automake / auto-something' then I should be able to do it, I just don't know how. Getting _anything_ to cross-compile for a system that old is certainly going to be a real chore, and i think i can safely say that nobody here has access to a machine that old to try it out on. i would recommend poking around one of the Solaris newsgroups (if there are any - in my experience SUN keeps any and all useful documentation under lock and key) and asking some of the SUN^H^H^HOracle gurus. But even then i would be surprised if anyone has a 2.1 box still running. It was end-of-life'd 12(!) years ago. It would surprise me if the new build tools (TCL-based) will bootstrap/compile on 2.1. But good luck... -- - 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] Creating repositories remotely
On Fri, Aug 12, 2011 at 10:15 AM, Sacha El Masry li...@devilray.eu wrote: Whereas I am happy to use ssh to upload to my own central vcs server, this becomes non-trivial for a) general users (non-developers) i would argue that non-developers do not (or should not!) generally set up new repositories. That's kind of like expecting a programmer to set up a new Corporate Identity-compliant PowerPoint template for the marketing department. b) those with limited hosting accounts Even the most limited hosters allow ftp access and most allow CGI access, and those two are all that is needed in order to host remote fossil repos. (IMO the ability to run over CGI is the killer feature of fossil, and i host all of my repos over CGI.) -- - 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] SunOS 5.1 build?
On Fri, Aug 12, 2011 at 3:45 PM, Tomek Kott tkott.s...@gmail.com wrote: Hahah, thanks all. I had no idea just how old that server was. It's a university system, so I'm not too surprised. I don't quite understand how CF9 can run on a machine that old but hey, that's not my issue. It MIGHT just compile for you on that box, assuming you've got a C compiler (SunStudio _ought_ to do). AFAIK the code base is C89-compatible with one or two small exceptions in the sqlite3 code (long long is C99). You might try backing up to a version older than about 2 months, so that you have a hand-written makefile and do not need the newer configure script. In that case you'll need to edit the makefile a small bit for Solaris (IIRC you just need to search for Solaris in the makefile). (As much as i dislike administering Sun systems, the fact that that box is still running is a testament to their rock-solidness.) -- - 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 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
-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 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
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./self-interest 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 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
On Fri, Aug 12, 2011 at 5:01 PM, Ben Summers b...@fluffy.co.uk 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 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 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 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
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: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
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
-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 12:33 PM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -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
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 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*. 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 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 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
Re: [fossil-users] New features for merging
On Fri, Aug 12, 2011 at 11:39 PM, Mike Meyer m...@mired.org 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 2:44 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 12, 2011 at 11:39 PM, Mike Meyer m...@mired.org 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. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] _FOSSIL_ vs. .fos Was: New features for merging
On Fri, Aug 12, 2011 at 5:24 PM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: 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. You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default? 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 -- D. Richard Hipp d...@sqlite.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] _FOSSIL_ vs. .fos Was: New features for merging
On Sat, Aug 13, 2011 at 12:42 AM, Richard Hipp d...@sqlite.org wrote: You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default While i'm all for Unix-style names, i think the name .fos might confuse more people than it would help, whereas _FOSSIL_ clearly has something to do with fossil, and the unconventional _ at the start and end clearly mean that there's something special about it (i.e. don't touch it). (At least i've always found it intuitive enough.) Might there not be a documentation impact (i.e., invalidating lots of older docs) if this particular default is changed? PS: i didn't know it could be renamed. -- - 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] _FOSSIL_ vs. .fos Was: New features for merging
On Fri, Aug 12, 2011 at 3:42 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 12, 2011 at 5:24 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: 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. You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default? Yes! If I had thought that was a possibility, I would have asked for it instead. mike ___ 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] _FOSSIL_ vs. .fos Was: New features for merging
On Fri, Aug 12, 2011 at 06:42:23PM -0400, Richard Hipp wrote: You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default? I think .fos is too random / short. .fossil would be fine as default on UNIX (if you can figure out how to mark _FOSSIL_ as hidden on Windows, that would be good too). 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] _FOSSIL_ vs. .fos Was: New features for merging
+1 - Original Message - From: Joerg Sonnenberger Sent: 08/13/11 05:01 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] _FOSSIL_ vs. .fos Was: New features for merging On Fri, Aug 12, 2011 at 06:42:23PM -0400, Richard Hipp wrote: You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default? I think .fos is too random / short. .fossil would be fine as default on UNIX (if you can figure out how to mark _FOSSIL_ as hidden on Windows, that would be good too). Joerg ___ 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
