Re: [fossil-users] Merging multi-level-branches
On Sun, Oct 17, 2010 at 12:18:20PM -0400, Richard Hipp wrote: On Sun, Oct 17, 2010 at 4:06 AM, Wolfgang rat...@stumvolls.de wrote: Hello I don't know, if the following behaviour is a feature, a bug or if this solution would be a feature request. I like to work with branches. Asuming: 1. i have a trunk development, using version 1, 2, 3 2. i started a branch name b1 at 1 and committed some changes 1.1.1, 1.1.2, 1.1.3 3. i started a second branch named b2 on the branch 1 at 1.1.2 using versions 1.1.2.1.1, 1.1.2.1.2 The above version numbers are given in CVS notation. If i decide to merge branch 2 to main trunk, i would expect, that merge b2 apllies patches 1.1.2.1.1, 1.1.2.1.2. But fossil merges the complete patch sequence starting from 1.1.1 to 1.1.2.1.2 to my trunk version 3. Fossil reads the commandline argument b2 and searches for the newest version with this tag and apllies all patches from the common base 1.1 until the found branch version. My expactation: Only diffs occuring on the branch should be apllied. I see only one chance: Applying all patches from the branch p2 using --cherrypick. Is this intended? The behavior is as intended. I like this behaviour intended. I just had the case of having a branch from trunk, and it had some changes I wanted to merge in to trunk, but I did not want all of them. So I can create a subbranch of 'branch', prepare it as I want it merged into trunk, and from trunk I can do: fossil merge subbranch But I wonder if a later merge in trunk like this will work fine: fossil merge branch 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
[fossil-users] Jurassic GUI 0.2.0
Hi, I've released a new version of Jurassic GUI. NEW: Timeline view and show diffs from arbitrary commits. http://code.google.com/p/jurassic-fossil/ ___ 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 change 'binary' to non-binary?
Fossil considers files to be binary if they contain the character '\000' if they contain one or more lines that are longer than 8192 bytes. Fossil is unable to do a line-by-line diff of files that are binary (according to the diffinition above) and hence cannot merge such files. There is no way to tell Fossil to treat binary files as text. It refuses to merge such files because it does not know now to. On Tue, Oct 19, 2010 at 1:20 AM, Ron Aaron r...@ronware.org wrote: Fossil decided that a particular SQL file is binary, and I can't figure out how to change its mind. Is there a way to tell fossil to stop treating a file as binary? -- Sending me something private? Use my GPG public key: AD29415D ___ 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
[fossil-users] Migrating from Subversion.
I'm sorry if this question has been raised before but I couldn't find sufficient content on this over web. Is it possible to convert an Apache Subversion repository into a Fossil repository (yet)? -- -nasa http://vikrant.co.in/ ___ 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] Migrating from Subversion.
On Tue, Oct 19, 2010 at 8:51 AM, Vikrant Chaudhary nas...@gmail.com wrote: I'm sorry if this question has been raised before but I couldn't find sufficient content on this over web. Is it possible to convert an Apache Subversion repository into a Fossil repository (yet)? There is not a command-line tool to do this yet. Several people are working on such tools, though. -- -nasa http://vikrant.co.in/ ___ 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
[fossil-users] How to change 'binary' to non-binary?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fossil decided that a particular SQL file is binary, and I can't figure out how to change its mind. Is there a way to tell fossil to stop treating a file as binary? All files have a binary representation, unless you're using a quantum computer (unlikely Fossil would work at all on one of those). Could you give us more information on what you're trying to do? Are you thinking of the binary/text transfer modes in FTP? Regards, Adam J Richardson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9lTEACgkQSUH6dLOqvqmA1wCeNabOtdN1XiL6KwVSjWb8OWPs 6/0AoKjqoab6ZOqc/s5zB5wk4NQV5vnx =E9Gx -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
[fossil-users] checkins related to XXX
Hello, I could not find the definition of what the ui shows as checkins related to ***, like when clicking on a branch through the Branches web menu. Can someone give one? Thank you, Lluís. ___ 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 push 302 error.
$ fossil push Server: http://pa...@www.example.net/fossil/books Bytes Cards Artifacts Deltas Send: 67653989 48 2 0 fossil: location: missing from 302 redirect reply I got this error, I simple have no idea how to try to work it out, nor what it does mean. In this repo I put few fairly large files (.pdf), but I should be well under the sqlite limits as all the books are less than 1gb and each one is about 50MB. Any insight? Thanks ___ 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] Managing file attributes of repository files
The only way I've been able to reliably set the execute bit when it isn't set already is to: $ fossil rm filename $ fossil commit -m you put your file in, you take your file out $ chmod +x filename $ fossil add filename $ fossil commit -m you put your file in and you shake it all about -- 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] Managing file attributes of repository files
On 10/19/2010 10:00 AM, Richard Hipp wrote: The main complication is getting the permissions to be transmitted reliably through a windows checkout. (Why is it always windows that gives trouble?) Going between *nix and windows systems, it seems every file windows touches gets an execute bit set. SVN handles this by having an svn:executable flag you can set on files. When checked out on a system with *nix-like permissions, the file gets the execute bit flipped, otherwise not. I like fossil keeping track of my actual permissions, but maybe add a `fossil chmod [+-]x filename` for windows only? On windows, the execute bit would be off on new files, untouched on modified files unless they've been fossil chmod'ed. -- 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] Managing file attributes of repository files
fossil chmod is a good idea! - Altu -Original Message- From: Joshua Paine jos...@letterblock.com To: fossil-users@lists.fossil-scm.org Sent: Tue, Oct 19, 2010 8:04 pm Subject: Re: [fossil-users] Managing file attributes of repository files On 10/19/2010 10:00 AM, Richard Hipp wrote: The main complication is getting the permissions to be transmitted reliably through a windows checkout. (Why is it always windows that gives trouble?)Going between *nix and windows systems, it seems every file windows touches gets an execute bit set. SVN handles this by having an svn:executable flag you can set on files. When checked out on a system with *nix-like permissions, the file gets the execute bit flipped, otherwise not.I like fossil keeping track of my actual permissions, but maybe add a `fossil chmod [+-]x filename` for windows only? On windows, the execute bit would be off on new files, untouched on modified files unless they've been fossil chmod'ed.-- Joshua PaineLetterBlock: Web applications built with joyhttp://letterblock.com/301-576-1920___ fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] 401 Error cloning a repository from a http server with auth
On October 18, 2010 at 08:02:15 PDT, Paolo Bolzoni wrote: dear list, I would like to use fossil as cgi program on a thttpd server. The problem is that it seems fossil cannot connect to a server that requires authorization. This problem manifests only when using the command line, when I use fossil via web browser it works fine. In other words, when I browse (with firefox or elinks) this address it works fine: http://name:p...@www.example.org/fossil/project1 when I use this command in my command line it does not: fossil clone http://name:p...@www.example.org/fossil/project1 project1 fossil answers 401. In other to use the authorization feature of thttpd I made a .htpasswd using htpasswd. Sadly I don't believe fossil supports this. The spec can be found at: http://tools.ietf.org/html/rfc2617 What I am doing wrong? Thanks Paolo The way you have your thttpd server set up looks like this: +--+ ++ ++ | user |-| thttpd |-| fossil | +--+ ++ ++ || ++ ++ | RFC2617| | fossil | | Auth | | user | ++ | auth | ++ Where user is one of: 1. A web browser 2. fossil doing a clone In order to successfully access fossil, you must first get through thttpd by providing an RFC 2617 authentication. Web browsers know how to do this just fine. The thttpd server sends back a 401 Authorization Required response which means to retry according to the returned www-authenticate header with a name and password (or hash thereof) encoded in an authorization header. (Organizations that support a single sign on mechanism often provide some kind of integration with this method of authorization.) Now, after getting through the thttpd server you must get through the standard fossil login screen or clone authentication. If you have gone through the thttpd authorization and thttpd has set REMOTE_USER as a result, fossil can be told to bypass its own authorization and use the user value from REMOTE_USER (see RFC 3875 http://tools.ietf.org/html/rfc3875 -- you set this as Allow REMOTE_USER authentication on the fossil - admin - access page in the web gui only, it's not available via the command line fossil settings). It allows you to only have to authenticate once (to thttpd) instead of twice (to thttpd and to fossil). When you try to clone you are not using a web browser. Instead the fossil executable that's trying to fetch a clone itself connects to thttpd and then gets a 401 response which it doesn't understand how to deal with and so never makes it through thttpd to talk to the remote fossil to begin the cloning process. So although the fossil executable accepts name and password (in the URL even) for clone, it does not know how to provide them to a web server (such as thttp) that is configured to require RFC 2617 authentication and furthermore, it's quite possible that the name and password used for the thttpd RFC 2617 authentication are different from the ones needed to satisfy the fossil user authentication. Currently the fossil clone command only accepts one set of user/password combination for cloning (the fossil user authentication ones -- which I believe it will pick up from the URL even though the name and password embedded in a URL are usually understood to be part of RFC 2617 authorization). If you wish to retain your thttpd authentication for accessing the fossil web pages, you will need to provide access on another port or perhaps via ssh port forwarding or else configure the thttpd server to skip its authentication stage for incoming application/x-fossil content types (that's what the clone command uses). Kyle___ 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 enhancements: Please test
There is a file-format enhancement to Fossil that seeks to make Fossil run more efficiently on projects with a large number of files in each checkout. Help in testing this enhancement will be appreciated. Fossil has been working great on projects with a thousand files or less in each checkout (which is to say, on most open-source projects). But some recent experiments with projects that have over 60,000 files in each checkout revealed inefficiencies. A small backwards-compatible enhancement to the file format is needed to address those inefficiencies. With each check-in, Fossil constructs a manifest which is a file listing all other files that are part of the check-in. The manifest works great for smaller projects, but when the number of files gets large, the overhead of handling the manifests becomes a problem. The present enhancement is to allow a check-in to be a delta-manifest. A delta-manifest, instead of recording every file in the check-in, only records the files that have changed from some prior check-in. Delta manifests are usually much, much smaller than regular manifests (called baseline-manifests) and can be processed more quickly. In the experimental enhanced Fossil, a delta-manifest is generated instead of a baseline-manifest if the delta-manifest is less than 1/125th the size of the baseline-manifest. The 125 threshold has been experimentally determined to give good results. Other changes in the experimental Fossil include a new repo-cksum setting. By doing: fossil setting repo-cksum off Fossil will skip a lot of cross-checking designed to detect errors early and prevent a software bug from causing loss-of-work. Additional information about these cross-checks can be found on the http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki webpage. The repo-cksum is enabled by default and we recommend that you leave it on where practical. But it does present a performance burden for large projects and can be turned off for those cases, if necessary. Finally, the experimental Fossil no long automatically generates the manifest and manifest.uuid files in the root directory of each check-out. Those files were never used by Fossil - they were generated for the convenience of the application. The makefiles for both Fossil itself and for SQLite depend on the manifest and manifest.uuid files being present. But other projects found them annoying, so they are now off by default. Use the fossil setting manifest on command to enable them. The enhancements are currently on the experimental branch: http://www.fossil-scm.org/fossil/timeline?r=experimental Unix users should be able to download and build an experimental version themselves. Windows users are encouraged to do the same if they are able, but for those that do not have a suitable build environment, a precompiled binary is made available at: http://www.fossil-scm.org/fossil-w32-201010192027.zip It will be very helpful if you can try out this experimental Fossil and report both successes and failures. This is a great opportunity for you to contribute to the Fossil project even if you don't have the skills or desire to go code diving. Some additional testing hints: To create a dummy repository for testing purposes, copy some existing repository then detach it: cp fossil.fossil test.fossil fossil test-detach -R test.fossil By detaching the test repository, you eliminate the possibility of accidentally syncing changes you commit to the test repository into your real repository. Other options that you might find useful: fossil commit --delta ... fossil commit --baseline ... fossil commit --test ... The --delta option to the commit command forces the generation of a delta-manifest even if Fossil would prefer to do a baseline manifest. Similarly, --baseline forces the generation of a baseline-manifest even if Fossil would prefer a delta. The --test argument to commit causes the commit to be a dry-run. Nothing is actually committed. Instead, the manifest is printed on standard output. If you do a lot of testing or experimentation with Fossil, another command-line option you might find useful is --sqltrace. That option (which works with all commands) prints all SQL statements that Fossil evaluates as they are evaluated. Thanks for testing out the recent Fossil changes. Please be sure to report either success or failure (whichever you encounter) with the new Fossil to this mailing list, or directly to me at d...@sqlite.org. -- 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 enhancements: Please test
On Tue, Oct 19, 2010 at 4:59 PM, Richard Hipp d...@sqlite.org wrote: Windows users are encouraged to do the same if they are able, but for those that do not have a suitable build environment, a precompiled binary is made available at: http://www.fossil-scm.org/fossil-w32-201010192027.zip First bug fix. Please use instead: http://www.fossil-scm.org/fossil-w32/20101019235054.zip Tnx. -- 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 enhancements: Please test
On Tue, Oct 19, 2010 at 04:59:11PM -0400, Richard Hipp wrote: [snip] Thanks for testing out the recent Fossil changes. Please be sure to report either success or failure (whichever you encounter) with the new Fossil to this mailing list, or directly to me at d...@sqlite.org. -- D. Richard Hipp d...@sqlite.org Everything seems to work fine under OpenBSD. Both delta and baseline seem to do as advertised. I tested with the chiselapp.com repository, which is tiny. ___ 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 enhancements: Please test
Hi Richard, These changes are interesting. fossil setting repo-cksum off If I use this setting on local checkouts and let's assume for some reasons that a commit damages the local database. If I don't have repo-cksum disabled on the remote repository (assume on http), will I get an error message when I push? I want to make sure that my remote repository never gets corrupted. That way, I can have this setting disabled on local database for faster commits and then once I push, I can know that something went wrong. Then, I can try to recover my loss of work using current checked-out code and a corruption-free remote repository. - Altu ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
