Re: [fossil-users] CGI and REQUEST_URI
On 17 Oct 2013, at 18:40, Richard Hipp d...@sqlite.org wrote: On Thu, Oct 17, 2013 at 1:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 7:17 PM, Richard Hipp d...@sqlite.org wrote: Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and will construct PATH_INFO from those two if it is missing. I'm working on a patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if REQUEST_URI is missing instead. i think the requirement on REQUEST_URI is in general a mistake (though one which appears to mostly work). There's no mention of REQUEST_URI in the CGI spec, though many CGI examples/howtos i'm looking at do use this (and some even imply that they are standard (e.g. http://www.cgi101.com/book/ch3/text.html), but i can find no proof of that). I've checked in a potential fix. The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or PATH_INFO. CGI should always supply PATH_INFO. SCGI should give us REQUEST_URI. Either way, Fossil will be happy now. I've just tried [403d937287] with Jetty, and it works. Thank you! (And I was anticipating making the fix myself after confirmation it was seen as something which should be fixed in fossil, but it was really kind of you to change it so quickly.) Since it looks like 1.28 is going to be out soon, I'll wait for that before updating the server. 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] CGI and REQUEST_URI
Hello, I've just tried upgrading from fossil 1.25 to fossil 1.27 on my server, which uses Jetty as the CGI server. I just see an error: Bad Request: missing REQUEST_URI and of course, Jetty isn't sending a REQUEST_URI. This environment variable isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty for not sending it: http://tools.ietf.org/html/rfc3875 It looks like the addition of SCGI support in http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the requirement for REQUEST_URI. Which one of fossil or Jetty needs fixing? Thanks, 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] Slight difficulty with symlinks
On 25 Nov 2011, at 22:02, Barry Kauler wrote: Hi guys, I am just getting started with Fossil again, after a brief fling back in late 2009. I was very impressed, but my project has lots of symlinks, which is what brought me to a halt before. When I created my woof2 repository, I ticked allow-symlinks. All seemed well, however when I did a test clone of the repository, symlinks were turned off, so when I did fossil open all I got were files, not symlinks. So, I thought, perhaps I need to put .fossil-settings/allow-symlinks (with content on) into the repository: # fossil add --dotfiles .fossil-settings I pushed that, then cloned, nup still no symlinks. Bye the way, does it cause any conflict have .fossil-settings in the repository? So then I thought of creating .fossil-settings/allow-symlinks after cloning and just before running fossil open ../woof2.fossil. Still no go. allow-symlinks is not a versionable setting. Is there a reason why it shouldn't be? It sounds like it should be as it affects the checked out files. To change it to a versionable setting: * Add a 1 in the versionable column the entry in ctrlSettings in db.c * Add '(versionable)' to the documentation below * Add to the list in settings.wiki 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] 'mostly static' Fossil on Solaris 8/9+
On 22 Nov 2011, at 22:10, Garth Dahlstrom wrote: Hi all, Short Question: Can anyone build a mostly static fossil executable on Solaris 8 or 9 and post it somewhere? Longer Explanation: The only Solaris box that I have capable of building anything is a Solaris 10 box; there are a handful of boxes that run still Solaris 8 and 9 (these are minimal installs). :( [...] So given that the only choices to get this to work on an older version are to either install/set-up an old Solaris 8/9 + build tools, or build a cross compiler... The former is not really an option for me. What if you create a Solaris 8 branded zone on the Solaris 10 box, and compile fossil there? 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] Need to configure an empty repository from command line
On 21 Nov 2011, at 01:13, Richard Hipp wrote:
On Sun, Nov 20, 2011 at 7:56 PM, Chris Peachment ch...@ononbb.com wrote:
I'm using fossil version 1.20 on Linux for both server and client
computers.
I want to use fossil command line instructions to initialise an
empty repository. I use:
fossil new test.fossil
but I can not find a command to provide the project-name value to
be stored in the config table.
There isn't one - or at least not a simple one. I always configure using the
web interface: just run fossil ui test.fossil and manually configure it
that way.
If you definitely, positively must do your configuration from the command
line, it can be done using raw SQL. Probably just a single INSERT statement.
But I'd have to go look up exactly what that INSERT statement would be. May
I suggest: Configure a dummy repository using fossil ui and then look in
the CONFIG table of the repository database to see where the project name got
inserted. It should be obvious from there what you need to do to insert that
name yourself.
While it seems a bit odd to be contradicting Richard about his own software,
I've written a simple script to create blank repositories for our clients which
sets the project name using the fossil configuration import command. When
you're creating lots of repositories, it's very boring and error-prone if you
don't script everything.
You have to write a configuration file before using the import command, and
although you're unlikely to want to write it by hand, the format is quite
simple. There's a snippet of Ruby code below which I think should get you
started (tip: examine the output of fossil configuration export first), email
me off list if anyone wants the entire repo generating script.
Ben
def config_entry(name, value)
l = %Q!#{Time.now.to_i} '#{name}' value '#{value}'!
config /config #{l.length}\n#{l}\n
end
File.open(mcr.config.tmp, w) do |f|
f.write config_entry('project-name', #{CLIENT_FULLNAME})
f.write config_entry('project-description', #{CLIENT_FULLNAME} ONEIS
Plugins)
f.write config_entry('index-page', /wiki?name=home)
end
system fossil configuration -R #{REPO_FILENAME} import mcr.config.tmp
File.unlink(mcr.config.tmp)
--
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] Forms are cleared in firefox, switch pages
On 3 Oct 2011, at 16:20, Lluís Batlle i Rossell wrote: On Mon, Oct 03, 2011 at 05:05:13PM +0200, Stephan Beal wrote: 2011/10/3 Lluís Batlle i Rossell virik...@gmail.com What would happen if JSON answers had not 'no-store'? Would not be 'no-cache' enough? It should be up to the json clients though. Sorry, my mistake - i meant no-cache, not no-store. So, as I tested, removing 'no-store' makes firefox remember the form in the case of back-forward in history. But clicking to the same url makes firefox still refetch the page contents. I think that's exactly what I want. Anyone against? Might be best to also add in 'private' Cache-Control: private, no-cache for a more explicit description of the intent of only showing content to the user who requested it. 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] Forms are cleared in firefox, switch pages
On 3 Oct 2011, at 17:37, Lluís Batlle i Rossell wrote: On Mon, Oct 03, 2011 at 05:13:35PM +0100, Ben Summers wrote: On 3 Oct 2011, at 16:20, Lluís Batlle i Rossell wrote: I think that's exactly what I want. Anyone against? Might be best to also add in 'private' Cache-Control: private, no-cache for a more explicit description of the intent of only showing content to the user who requested it. That's for multi-user web-browsers, isn't it? I don't know of any. It's not aimed at browsers, it's aimed at intermediate caches which proxy multiple users. I also can't forecast a meaning for private+no-cache. I means roughly the same as no-cache, but allows for older caches. If ever appears the need, let's introduce private. I committed the removal of no-store, btw. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] same user, multiple logins: the problem and a potential solution
On 15 Sep 2011, at 00:17, Stephan Beal wrote: As Richard mentioned earlier, the current fossil login mechanism does not tolerate a given user being logged in multiple times (each new login invalidates the previous one). While this almost certainly isn't a real limitation for the HTML interface, it will eventually become one for the JSON interface. e.g. i might have one applet for polling a timeline and another for polling tickets. That wouldn't work right now unless i force a re-login from each client (and can avoid the inevitable login/poll race condition between the two apps). In a recent project of mine i have the same limitation of one login per user (because i don't want the db filling up with stale login state data) but i allow multiple logins for one user by recycling the login auth token values (analog to fossil's cookie value) if a user performs a login while a login is already active. The login op then always returns the same auth token for the given user/password until an explicit logout is performed (which clears the user.cookie value) or fossil cleans up the cookie because it expired (i don't know if it currently does any cookie cleaning but it does store the expiry time in user.cexpire). To solve this, you could use a different way of creating tokens with simple cryptographic signatures. You could concatenate the username and first 3 octets of the IP address, then sign it with a single secret key using an algorithm like HMAC-SHA1. [1] For example, you could form the string stephan:192.168.0 then sign it with the secret key, and get stephan:192.168.0:38fa112673be4946702a74d1d0d1c0b6bd9f0162 To limit the validity of the tokens, include the time in the string being signed, and check it's in an acceptable range. Advantages are that no state is stored in the database and multiple logins are possible, with simpler code.[2] You can invalidate all logins by changing the secret key, but can't invalidate individual sessions. If you wanted to support logins from multiple locations in a browser which is run in multiple networks, include the partial IP address in the cookie name. Ben [1] https://secure.wikimedia.org/wikipedia/en/wiki/HMAC [2] Although there are some subtle things you have to be careful of, mainly timing attacks. Safe approach: when checking the signature, don't use strcmp(), hash both strings then strcmp() the hashes. -- 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] JSON authentication: meshing with the cookie mechanism
On 14 Sep 2011, at 18:26, Stephan Beal wrote: On Wed, Sep 14, 2011 at 7:24 PM, Stephan Beal sgb...@googlemail.com wrote: No, but for supporting clients which don't have cookies support. e.g. i've written Java HTTP client apps (using a similar API to this one, actually) but the client code doesn't support cookies, so it has to pass around its authentication in the JSON request. Cookies are, for purposes of the JSON API, the fallback and not the default. BTW: many SOAP interfaces do this as well. When logging in you get a token (which fossil stores as a cookie), and that token has to be included in requests which require non-guest access. HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. 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] JSON authentication: meshing with the cookie mechanism
On 14 Sep 2011, at 21:36, Richard Hipp wrote: On Wed, Sep 14, 2011 at 4:30 PM, Joshua Paine jos...@letterblock.com wrote: On 9/14/2011 4:22 PM, Ben Summers wrote: HTTP basic authentication is widely supported in HTTP client libraries, and much less hassle to use than passing tokens around. The three major downsides with HTTP Basic Auth are: 1) No pretty login page 2) No reliable way to logout in most browsers 3) Requires sending the username and password over the wire 1 and 2 are irrelevant for a JSON API, and fossil's web ui already sends the username and password in the clear over the wire unless you're using HTTPS, so this is no greater risk, and it inherits the protection that an HTTPS setup provides. I vote for HTTP Basic Auth, provided that someone can confirm the major browser AJAX functions support it. Note that Basic Auth is normally handled by the web server, not the client application. The web server checks the credentials and then sets the REMOTE_USER environment variable. Fossil honors the REMOTE_USER environment variable in CGI mode, so you can use Fossil with Basic Auth. But, it comes with all the downsides listed above, plus it means that the Admin/User page will no longer work for setting and changing passwords since the passwords are now stored in the web server, not in Fossil. I believe that if you don't ask the web server to handle it, it'll just pass on the raw headers to the CGI script. Apache certainly works that way with proxying. One other thing: I don't think Basic Auth allows anything equivalent to the current nobody user or the anonymous user. If you don't have a valid login and password you cannot see anything at all. That would be downside #5, if I'm counting right It's probably best implemented without enforcing the use of basic auth. So if the headers aren't present, don't return a 401, just do everything as now. You then get the best of both worlds, tokens or cookies and the option to use basic auth when it's the easiest mechanism available. 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] authentication in JSON: anonymous vs. guest user
On 11 Sep 2011, at 05:55, Stephan Beal wrote: In a JSON context, link-following is not an issue. There are no links, as such, in JSON docs - though individual JSON strings might incidentally contain HTML link strings, bots don't generically try to extract HTML text from JSON. Doing anything at all with the data requires writing an app-specific bot to do it. Given that, would be against fossil's nature if i reduce the JSON API's authentication to only 2 levels: read and write? Non-logged in users would be read-only and logged in would have write access only if their user profile allows it (and if it doesn't then logging in for JSON access doesn't have any benefit at all for the client). Private repositories will need the user to authenticate to get read only access. I trust you're planning to respect the permissions for the anonymous user? 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] how to use versionable properties?
On 3 Sep 2011, at 14:05, Stephan Beal wrote: Hiya! Per the 'settings' page: Settings marked with (v) are 'versionable' and will be overridden by the contents of files named .fossil-settings/PROPERTY. to use this, do i need to manually add the .fossil-settings files or are they created/added via versioning-aware fossil commands? You need to manually create and edit those files. The settings commands do not create or modify those files, and just work exactly as they did before the implementation of versionable settings. It's just that the values of these settings can be overridden by the contents of files within .fossil-settings. I tried to explain it here http://fossil-scm.org/index.html/doc/trunk/www/settings.wiki and would welcome suggestions for improving that page. 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] Testing for a release
On 26 Aug 2011, at 21:31, Matt Welland wrote: I have switched to the new trunk and I think it address the issue I had with symlinks (sent in separate mail). Thanks! The empty-dirs works as advertised but I have an enhancement request. If I specify a multilevel directory and the upper levels do not exist the directory is silently skipped. Either use the equivalent of mkdir -p or put out a warning if the required directories failed to be created. You're right, it should do a recursive creation. I'll make that chance in a day or two. I suspect I didn't implement it because there wasn't a handy 'mkdir -p' in file.c, and I was just experimenting at the time. You should, however, have seen a warning like this: couldn't create directory path/of/dir as required by empty-dirs setting If you didn't see that, it's a bug which needs fixing. Steps to reproduce would be useful. Thanks. Ben ___ 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 15 Aug 2011, at 21:42, Matt Welland wrote: 2011/8/15 Lluís Batlle i Rossell virik...@gmail.com 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
[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] 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 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] X-Frame-Options http header
On 9 Aug 2011, at 22:14, Martin S. Weber wrote: So I wanted to use javadoc/scaladoc style documentation and take advantage of fossils embedded documentation -- I put the scaladoc under repo/docco and happily was going to http://server:port/repo/doc/trunk/docco/index.html - but there noscript was already waiting for me, saying No, no!. I couldn't convince it otherwise, so I turned the X-Frame-Options http header over to SAMEORIGIN instead of DENY and recompiled. Now, with wikis and such I can see how there's a danger of IFRAMEs, click jacking and what not. On the other hand, there's a valid use-case for using iframes, where x-frame-options really should be SAMEORIGIN. Couldn't there be a setting to tune, or a list of glob patterns for which to turn X-Frame-Options to SAMEORIGIN (or, the other way round, to DENY) ? Changing to SAMEORIGIN isn't going to lose much in terms of security, as you'd have to have exploited something else first. I choose DENY when I added that header to be as paranoid as possible, not realising it'd break your documentation (sorry!). You can change the value of the header in the web server hosting the CGI script, if you're hosting that way. Under Apache you would use mod_headers. It sounds like the default should change, and those who really care should adjust their web server. 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] X-Frame-Options http header
On 10 Aug 2011, at 15:11, Stephan Beal wrote: On Wed, Aug 10, 2011 at 9:24 AM, Ben Summers b...@fluffy.co.uk wrote: It sounds like the default should change, and those who really care should adjust their web server. Just FYI: the vast majority of users do not have admin-level rights to their publicly-hosted servers. i.e. fossil changes which _require_ adjustments to the web server config are likely to cost fossil a user or two. My primary use of fossil is over CGI on Apache, but i have very little control over the apache config on my 2 hosters (i can't change modules, i can only change certain settings). Yes, that was why I suggested changing the default to something which caused minimal problems. The paranoid will probably be running their own servers anyway. In any case, the DENY setting only affected those doing something fancy. 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] 83c032de7f1 fails to build :( - manifest.uuid is missing
On 4 Aug 2011, at 16:35, Stephan Beal wrote: Hi! i just updated to 83c032de7f1 and i'm getting: make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. i've done a 'make distclean' and './configure --prefix=$HOME'. is there something else i need to turn off/on here? i vaguely remember that creation of the manifest became optional, but i don't remember turning it off for this repo. Aha... there it is: ~ fossil set manifest 1 So the problem is solved, but i'll post this anyway in case someone else stumbles across it and goes googling. This use of settings for things which affect the checked out repository was a big stumbling block for me while I was getting into fossil. I've got some changes in a branch which resolve this with 'versionable' settings, where the values optionally go in files called .fossil-settings/[setting] http://fossil-scm.org/index.html/timeline?r=ben-testing It allows mixed use of settings and these versioned settings for a clean migration. Do have a play, feedback is welcomed. I've been using this version for a good few weeks, and it's so much easier to understand. Type fossil help settings for details! 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] changes status cmds within sub-directory
On 22 Jul 2011, at 12:03, Lluís Batlle i Rossell wrote: On Sun, Jul 10, 2011 at 01:03:06PM -0400, Martin Gagnon wrote: Le 2011-07-10 à 11:05, Ben Summers b...@fluffy.co.uk a écrit : Answering the question about breaking existing scripts, the output is identical when used at the root. Unless you're running scripts in a sub-directory, nothing needs to change. Ben That's true... And I like the latest suggestion as well... Could someone implement this subdirectory awareness also for fossil ls? Why is that useful? I'll add it if it is useful, but it's not a command which relates to the files you're working on. Is anyone else using the ben-testing branch, with this and the other changes I made? (versionable settings, SSL client certs, empty-dirs setting) 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] changes status cmds within sub-directory
On 22 Jul 2011, at 13:09, Lluís Batlle i Rossell wrote: On Fri, Jul 22, 2011 at 12:36:33PM +0100, Ben Summers wrote: On 22 Jul 2011, at 12:03, Lluís Batlle i Rossell wrote: On Sun, Jul 10, 2011 at 01:03:06PM -0400, Martin Gagnon wrote: Le 2011-07-10 à 11:05, Ben Summers b...@fluffy.co.uk a écrit : Answering the question about breaking existing scripts, the output is identical when used at the root. Unless you're running scripts in a sub-directory, nothing needs to change. Ben That's true... And I like the latest suggestion as well... Could someone implement this subdirectory awareness also for fossil ls? Why is that useful? I'll add it if it is useful, but it's not a command which relates to the files you're working on. It helps me knowing what is in the repository and what not. Maybe the 'extras' command could have some kind of subdirectory view too. I realised that the extras needed to be relative to the current working directory as well as status/changes, so I did that too. It's in both the ben-testing and ben-changes-report branches. I use 'fossil ls' with grep from time to time, to know what is upstream and what not. Maybe this is a bad way of doing that, I don't know; but it works fine for what I've been doing. You should use extras to do this. Is anyone else using the ben-testing branch, with this and the other changes I made? (versionable settings, SSL client certs, empty-dirs setting) I'm not using it; if you need testers to achieve some consensus for a merge to trunk, I could spend some time testing the basics at least. That would be wonderful, thank you! 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] Avoiding problems with fossil default Makefile (Steve Bennett)
On 21 Jul 2011, at 07:42, Steve Bennett wrote: On 20/07/2011, at 7:16 PM, Ben Summers wrote: I'm concerned that typing 'make' on obscure platforms builds subtly broken binaries. For example, on Solaris, it'll build one which truncates your passwords to 8 characters. I propose that we whitelist platforms where the default Makefile is known to work, and force the use of ./configure for all other platforms. Here's an example change to the build system which only allows Linux and Mac OS X to use the default Makefile: http://fossil-scm.org/index.html/info/14d1e44957 I have also corrected the documentation. Suggesting people type ./configure; make will just use the default Makefile on the platforms where it really matters! You need to use the explicit ./configure; make -f GNUmakefile to pick up the autosetup generated Makefile. The autosetup/configure stuff is quite new. Aren't we just waiting until it has had some more testing until switching over to it for all (non-windows) platforms? Probably. It's just that the current trunk has a 'broken' fossil on Solaris and the instructions on how to use it are wrong. Probably makes sense to rename Makefile to Makefile.classic and have configure create Makefile from Makefile.in though. Yes! 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] Avoiding problems with fossil default Makefile
I'm concerned that typing 'make' on obscure platforms builds subtly broken binaries. For example, on Solaris, it'll build one which truncates your passwords to 8 characters. I propose that we whitelist platforms where the default Makefile is known to work, and force the use of ./configure for all other platforms. Here's an example change to the build system which only allows Linux and Mac OS X to use the default Makefile: http://fossil-scm.org/index.html/info/14d1e44957 I have also corrected the documentation. Suggesting people type ./configure; make will just use the default Makefile on the platforms where it really matters! You need to use the explicit ./configure; make -f GNUmakefile to pick up the autosetup generated Makefile. 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] Avoiding problems with fossil default Makefile
On 20 Jul 2011, at 12:54, Stephan Beal wrote: On Wed, Jul 20, 2011 at 11:16 AM, Ben Summers b...@fluffy.co.uk wrote: I'm concerned that typing 'make' on obscure platforms builds subtly broken binaries. For example, on Solaris, it'll build one which truncates your passwords to 8 characters. That's not broken, though - that's the feature set provided by the OS. Admittedly, it's semantically broken but it's not technically broken. The bug is in Sun's heavy reliance on 1st-semester Chinese I.T. students to write their most central OS software (how else can one explain the CLI interface of SunCluster 3.1 and earlier?), and not fossil. I think this is a side effect of the binary compatibility guarantee, which means getpass() can't return more than 8 characters to avoid breaking binaries from the Solaris 2 era. getpassphrase() is provided for new applications. The autosetup scripts check for this, and if it's available, it'll be used. I had terrible problems getting fossil to work, because it was silently truncating my 10 character passwords to 8 and I couldn't authenticate with the server. Regardless of the reasons for this breakage, it's an extremely bad user experience. However, I'm a little unclear about what you're proposing. Are you suggesting that fossil should only support majority operating systems, or that it's desirable to produce binaries which almost work but will infuriate people who try to use them? (For clarity: I'm perfectly happy to continue making fossil work on Solaris, and I'm not expecting anyone else to do anything about it.) I have also corrected the documentation. Suggesting people type ./configure; make will just use the default Makefile on the platforms where it really matters! You need to use the explicit ./configure; make -f GNUmakefile to pick up the autosetup generated Makefile. That is of course a problem, though. Perhaps we should rename the default makefile to Makefile.unix (or similar). Since GNU make will look for GNUMakefile by default, we could then keep the documentation (and convention) that './configure make' will work as-is for GNU platforms resp. platforms where GNU make is used, but will fail with makefile not found for non-GNU make. I agree that renaming the Makefiles would be sensible. However, I believe there is resistance to changing the build system if at all possible, hence, I made minimal changes. Although being consistent on every platform and requiring ./configure make might be a reasonable solution. 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] autosetup and GNUmakefile
On 13 Jul 2011, Martin Gagnon wrote: There's no a big issue here.. it's just a kind of philosophical question. I've notice that autosetup ./configure will create a GNUmakefile instead of a Makefile. In my OpenBSD system, bsd make doesn't use the GNUMake file when I type make. So if I type: # ./configure # make It will use the orignal Makefile that still is on the repository. So it's pretty easy here to be confused and someone can try to put special flag to the ./configure call with no effect. So seing that.. I've delete the old Makefile and type make again.. Bsd make doesn't use GNUmake file at all.. At least, autosetup have create a BSD compatible make file (even if it's named GNUmakefile). so I can type make -f GNUmakefile and it work fine.. just confusing... May be same kind of confusion may happens on other system. I guess it would be less confusing to generate a makefile named Makefile and may be rename the old static Makefile something else. Or may be someone might have a better idea to remove the confusion. I'm worried that the normal Makefile will produce a subtly broken binary, and GNUmakefile will be ignored. For the current release version, if I compile with a 'make' command on Solaris, I get a binary which will silently truncate all passwords entered to 8 characters because HAVE_GETPASSPHRASE is not defined. If I run the ./configure script, Solaris make (which isn't GNU make) will ignore GNUmakefile and build a broken binary again! (Note that the autosetup stuff doesn't work on Solaris yet. Steve has a fix which has yet to be committed.) There appear to be two solutions: 1) Delete the current Makefile, get autosetup to produce a Makefile, and require every platform to ./configure. 2) Whitelist platforms where Makefile works correctly. If you attempt to use Makefile on anything else, it asks you to run ./configure make -f GNUmakefile. I understand the desire to minimise the changes to the existing build system, but this compromise is dangerous. It relies on non-standard behaviour of GNU tools, which aren't likely to be used by default on the platforms most affected. This almost guarantees confusion and breakage on the platforms it's supposed to help. As a user of fossil on an unusual platform, I really appreciate all the effort put into portability: thank you! 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] autosetup and GNUmakefile
On 14 Jul 2011, Stephan Beal wrote: On Thu, Jul 14, 2011 at 9:11 AM, Ben Summers b...@fluffy.co.uk wrote: If I run the ./configure script, Solaris make (which isn't GNU make) will ignore GNUmakefile and build a broken binary again! The maintainer of GNU Make, Paul Smith, writes (and i agree with him wholeheartedly, after having spent many painful years maintaining Solaris systems): Don't hassle with writing portable makefiles, use a portable make instead! That's Rule #1 on Paul's list of Make rules ( http://make.paulandlesley.org/rules.html). gmake is available for every odd platform out there, though it is not always installed by default. I'm not arguing for or against using GNU make, I'm just suggesting that if typing ./configure make or even just make builds a broken binary without any error message, then it's probably not the best solution. 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] changes status cmds within sub-directory
When working on my project, the current directory is always a sub-directory of the checkout root. Perhaps I'm too used to subversion, but I'm finding the checkout root-relative listing rather confusing. You can't copy and paste a filename to, say, an add command without having to think about removing the sub-directory name. I wonder if modifying the output when you're in a sub-directory would be a good idea to help the people who work like this. (Although I suspect that the vast majority of people work in the root directory.) If the current directory was the 'two' sub-directory, currently the output might look like this: $ fossil status ADDED one/hello.txt ADDED two/world.txt EDITED two/src/display.c I'd find it easier to work with if it were displayed like this: $ fossil status In sub-directory two: ADDED world.txt EDITED src/display.c 1 other change. Use --show-all option to list all changes. I've implemented this in a branch: http://fossil-scm.org/index.html/info/e0d2e1f9b8 If you happen to be in the root directory, or use the --show-all option, the output is identical to the current version. Does this sound like a good idea? 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] Needed: volunteer to autoconf Fossil
On Jun 14, 2011, at 13:45 , Alexander Vladimirov wrote: actually autoconf requires GNU M4, and somehow tends to bring automake and libtool to your system as well. Yeah, that's for the developers. But users just need to run the Bourne shell configure script. As an intermediate stage, a simple script to put the output of uname -s into the Makefile might be a way to get going? http://fossil-scm.org/index.html/timeline?r=configure-make autotools are a bit of a nightmare, and possibly overkill for a project which is so inherently portable and self-contained. 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] Testing new features
On Thu, 02 Jun 2011 16:27:16 -0700, Jan Danielsson wrote: On 06/02/11 22:05, Ben Summers wrote: I've created a new branch, ben-testing, with the new features I've been working on. I'm going to be using this version from now on to make sure it's well tested before it's considered for merging into trunk. It adds: * SSL client certificate support [---] See http://www.fossil-scm.org/index.html/timeline?r=jan-clientcert for alternative SSL client certificate support. I'm quite annoyed at myself for not noticing your implementation until after I'd written mine. The difference between the two is that I've implemented the simplest possible thing which could work, and you've added complete certificate management, including managing the server's certificate. Your implementation avoids the need to specify the client certificate on every clone command, but mine requires it for each repo, storing the pathname in the ssl-identity setting for later operations. Personally I just want to be able to use client certificates, and don't mind which approach is taken. 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] Testing new features
I've created a new branch, ben-testing, with the new features I've been working on. I'm going to be using this version from now on to make sure it's well tested before it's considered for merging into trunk. It adds: * SSL client certificate support * Versionable settings (eg specify ignore-glob as the file .fossil-settings/ignore-glob) * empty-dirs setting, for creating empty directories on update or checkout I'd appreciate any help in testing it, and feedback on the implementation. Unless you want to use empty-dirs as a non-versioned setting, you can use a normal release on the server. I'll keep the branch up to date with releases as they're made. To get started with the settings changes, type fossil help settings, and for the SSL certs, connect to a server which requests a client certificate for instructions, or type fossil help clone. Thanks! 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] Testing for versionable settings and empty-dirs
Hello, I've tidied up the versionable-settings branch, which also adds an empty-dirs setting. I welcome feedback and testing -- if you can, let me know what you think, and any bugs you find. http://fossil-scm.org/index.html/timeline?r=versionable-settings fossil help settings should tell you everything you need to know, and it will spit out warnings when non-versioned and versioned settings conflict. I've been wondering whether it's worth trying to do something with these in the import command, converting the potentially multiple .gitignore files to a single .fossil-settings/ignore-glob file. However, for my use case of importing from svn, the git svn command won't commit the generated .gitignore files. Also, I had hoped that something with empty-dirs could be done for svn import, eg using the $GIT_DIR/svn/refname/unhandled.log file, but it's messy. Maybe it's not worth it, as it's not going to be a particularly good or complete solution. I presume anyone converting from svn to fossil will keep the old repo around in case an old version needs to be extracted and actually used. The pre-fossil history in the fossil repo works well enough to understand the changes made. 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] Versionable settings, empty dirs (and symlinks?)
On 21 May 2011, at 18:29, Ben Summers wrote: As a first step, I've made an experimental patch to see what the reaction is, and whether the approach is worth tidying up: ... * Versionable settings ... * empty-dirs setting I've created a branch which very roughly implements these changes: http://fossil-scm.org/index.html/timeline?r=versionable-settings I wouldn't use it for real work, consider it a proof-of-concept for now. If there's an indication it's worth doing and some feedback on whether the approach is correct, I'll write a list of everything that's needed to make it production ready and get on with it. Regarding the symlinks, after reading the mailing list thread about them, I'm less enthusiastic. I will take a look at the code and see what needs to be done before merging. 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] Versionable settings, empty dirs (and symlinks?)
Hello, I've been using fossil for a few repos, and I really like the system. I'm about to move my final repo to it, but it's quite a big project and will require a bit of work to fit in with fossil. In particular, it assumes the SCM supports empty directories and symlinks. Also, in my current use, I've found the ignore-glob setting a bit cumbersome as it's not versioned. Since these issues have come up in the past, I thought I might have a go at adding support for them in fossil instead of modifying my code to cope. I'm not 100% sure this is best strategy, as there's a lot to be said for only requiring the lowest common denominator in an SCM. As a first step, I've made an experimental patch to see what the reaction is, and whether the approach is worth tidying up: http://pastebin.com/tbKGu3s6 This adds (badly): * Versionable settings The ignore-glob, binary-glob, crnl-glob and manifest settings can be version controlled. Add a directory .fossil-settings to your project, and within that, create a file named after that setting, eg '.fossil-settings/ignore-glob'. If this file exists, it'll be used in preference to the setting in the database. Glob parsing has been changed to allow multi-line settings, so you can do one glob per line as well as one line full of comma separated globs. * empty-dirs setting Each line of this setting specifies a directory name. When you checkout or update, those directories are created. Since the UI doesn't allow multi-line settings, you'll have to use a versionable setting for now as '.fossil-settings/empty-dirs'. I had a quick look at supporting symlinks, but wasn't entirely sure the best approach or where to start in the code. I wondered about having artefacts which contained the target of the symlinks, and were flagged somehow so they were written as symlinks instead of regular files. Any thoughts? I realise these changes may go against fossil's philosophy and not be suitable for inclusion. It was fun poking around the code. 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] Can't clone repo on Solaris 10 over https
On 16 May 2011, at 21:42, Ben Summers wrote: I'm getting login failed errors when attempting to clone a repo over https on Solaris 10, but the same command and repo works fine on Mac OS X. Cloning the repo over http from the Mac works fine. The https server is running Solaris 10 and the Jetty web server. I've tracked the problem down, and it was nothing to do with https vs http. On Solaris, getpass() will only return up to 8 characters. On Mac OS X, it returns up to 128 characters. My password for the https repo was 10 characters long, and the test clone over http used a default 6 character password. Solaris provides getpassphrase() which returns up to 257 characters. When I change fossil to use this instead of getpass(), everything works fine. I'll submit a patch to use getpassphrase() and build nicely on Solaris (you need to hack the makefile a bit as well). 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] Can't clone repo on Solaris 10 over https
Hello, I'm getting login failed errors when attempting to clone a repo over https on Solaris 10, but the same command and repo works fine on Mac OS X. Cloning the repo over http from the Mac works fine. The https server is running Solaris 10 and the Jetty web server. Sessions below. I'd appreciate any suggestions for the next step in working what the problem is. Thanks. Ben === Mac OS X === $ fossil clone https://b...@example.com/test test.fossil password for ben: Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 152 2 0 0 Sent: 690 28 0 0 Received:9841 26 7 0 Total network traffic: 694 bytes sent, 8981 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 7dc5533e64b958f30bbdb3b74179e9076e9f8749 server-id: 166b4cbdc835ef170e035a5a2d8e0851f4a919e9 admin-user: ben (password is dba7d7) $ fossil version This is fossil version [047e06193b] 2011-04-13 12:05:18 UTC === Solaris 10 === $ fossil clone https://b...@example.com/test test.fossil password for ben: Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 152 2 0 0 Sent: 690 28 0 0 Error: login failed Received: 52 1 0 0 Sent: 43 0 0 0 Error: login failed Received: 52 1 0 0 Total network traffic: 959 bytes sent, 0 bytes received fossil: server returned an error - clone aborted $ fossil version This is fossil version [047e06193b] 2011-04-13 12:05:18 UTC === Mac OS X === $ fossil server test.fossil (log into web interface, change permissions so you need to log in to clone) === Solaris 10 === $ fossil clone http://ben@192.168.36.39:8080 test_mac.fossil password for ben: Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 152 2 0 0 Sent: 690 28 0 0 Received:9803 26 7 0 Total network traffic: 687 bytes sent, 8999 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 7dc5533e64b958f30bbdb3b74179e9076e9f8749 server-id: f45e96177a166f49359791f8111d44734ca7ceea admin-user: ben (password is 5478b9) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Converting svn to fossil
I've written a quick blog post on how to convert simple subversion repositories to fossil as the info didn't seem to be readily out there: http://bens.me.uk/2011/convert-simple-svn-to-fossil I did discover something which might be a bug. If you don't include the --full-tree on the git fast-export command, your fossil repository omits any files which were included in the very first svn revision, but never modified. It's possible I'm using the wrong commands, but reading the docs didn't suggest any obvious mistakes. I'm looking forward to trying this with my main repository, which is significantly more complex, and makes much use of svn:externals, symlinks and svn:ignore. I suspect the effort to rearrange the project will be worth it. :-) 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
