[fossil-users] Converting from mercurial
Hello, As the lack of friendlyness I've always felt with git, before using fossil I used mercurial. If I wanted to convert any mercurial repository to fossil, how should do that? Has anyone done that? 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
Re: [fossil-users] Converting from mercurial
Le 2011-07-18 à 09:17, Lluís Batlle i Rossell virik...@gmail.com a écrit : Hello, As the lack of friendlyness I've always felt with git, before using fossil I used mercurial. If I wanted to convert any mercurial repository to fossil, how should do that? Has anyone ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] tar file is different then zip file
I have converted a cvs repo to fossil. I checked if the tag release_v5_1_0 would yield the same number of files as you can see from this timeline fragment it is version 186f4fdca4 [186f4fdca4] brokerhost geintroduceert * Upd mxflex/gbo/app_po.inc: 1.39 * Upd mxflex/gbo/app_bo.inc: 1.36 (user: renez, tags: trunk, release_v5_1_0) mxflex/gbo/app_bo.inc [diff] mxflex/gbo/app_po.inc [diff] The tar file contains 2 directories mxflex-186f4fdca41c087b(has 991 files) xflex-186f4fdca41c087b(has 2 files) while the zip file contains only one directory mxflex-186f4fdca41c087b(has 993 files) The tar file doesn't produce the release while the zip does. -- Rene ___ 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] tar file is different then zip file
On Mon, Jul 18, 2011 at 3:32 PM, Rene renew...@xs4all.nl wrote: I have converted a cvs repo to fossil. I checked if the tag release_v5_1_0 would yield the same number of files as you can see from this timeline fragment it is version 186f4fdca4 [186f4fdca4] brokerhost geintroduceert * Upd mxflex/gbo/app_po.inc: 1.39 * Upd mxflex/gbo/app_bo.inc: 1.36 (user: renez, tags: trunk, release_v5_1_0) mxflex/gbo/app_bo.inc [diff] mxflex/gbo/app_po.inc [diff] The tar file contains 2 directories mxflex-186f4fdca41c087b(has 991 files) xflex-186f4fdca41c087b(has 2 files) while the zip file contains only one directory mxflex-186f4fdca41c087b(has 993 files) The tar file doesn't produce the release while the zip does. Perhaps the long filename support in tarball generator is busted. Do the two files that differ have very long pathnames? Are they the longest two pathnames in the repository? -- Rene ___ 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] tar file is different then zip file
On Mon, 18 Jul 2011 15:38:07 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 3:32 PM, Rene wrote: I have converted a cvs repo to fossil. I checked if the tag release_v5_1_0 would yield the same number of files as you can see from this timeline fragment it is version 186f4fdca4 [186f4fdca4] brokerhost geintroduceert * Upd mxflex/gbo/app_po.inc: 1.39 * Upd mxflex/gbo/app_bo.inc: 1.36 (user: renez, tags: trunk, release_v5_1_0) mxflex/gbo/app_bo.inc [diff] mxflex/gbo/app_po.inc [diff] The tar file contains 2 directories mxflex-186f4fdca41c087b(has 991 files) xflex-186f4fdca41c087b(has 2 files) while the zip file contains only one directory mxflex-186f4fdca41c087b(has 993 files) The tar file doesn't produce the release while the zip does. Perhaps the long filename support in tarball generator is busted. Do the two files that differ have very long pathnames? Are they the longest two pathnames in the repository? -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org [1] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users [2] xflex-186f4fdca41c087b has xflex-186f4fdca41c087b/mxflex/xbr_bus/general/gui/smarty/internals/core.assemble_plugin_filepath.php mxflex-186f4fdca41c087b has mxflex-186f4fdca41c087b/mxflex/xbr_bus/general/gui/smarty/internals/core.process_cached_inserts.php which is 1 shorter. If I do a tar bal from the head i get this in the top directory 22b79fe24110d d22b79fe24110d -ffd22b79fe24110d x-ffd22b79fe24110d 2b79fe24110d ex-ffd22b79fe24110d flex-ffd22b79fe24110d xflex-ffd22b79fe24110d 79fe24110d fd22b79fe24110d lex-ffd22b79fe24110d b79fe24110dffd22b79fe24110d mxflex-ffd22b79fe24110d while the zip just produces mxflex-ffd22b79fe24110d It seems how closer I come to the latest the more directories the tarbal creates. It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. -- Rene ___ 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] tar file is different then zip file
On Mon, Jul 18, 2011 at 4:09 PM, Rene renew...@xs4all.nl wrote: It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. What version of Fossil are you running on the server, and what version are you running locally? -- 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] tar file is different then zip file
On Mon, 18 Jul 2011 16:15:50 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 4:09 PM, Rene wrote: It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. What version of Fossil are you running on the server, and what version are you running locally? Fossil version 1.18 [5acc3e4cc4] 2011-06-29 17:10:05 the server is my localhost -- Rene ___ 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] tar file is different then zip file
On Mon, 18 Jul 2011 16:15:50 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 4:09 PM, Rene wrote: It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. What version of Fossil are you running on the server, and what version are you running locally? Upgrading to Fossil version 1.18 [06e9ca23e7] 2011-07-18 20:04:34 doesn't make a difference -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] The fossil service command
Thomas Schnurrenberger's fossil service command - for running Fossil as a windows service - is now on the trunk. But I wonder: The name of this command is very similar to fossil server and might be confusing. Do we need to change it to something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? -- 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] The fossil service command
On Mon, Jul 18, 2011 at 10:51 PM, Richard Hipp d...@sqlite.org wrote: something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? i'd prefer win-service, but i don't use windows so i don't get a vote. or maybe: fossil M$ervice ;) -- - 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] tar file is different then zip file
On Mon, 18 Jul 2011 16:15:50 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 4:09 PM, Rene wrote: It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. What version of Fossil are you running on the server, and what version are you running locally? odd the command fossil tarball ffd22b79fe24110d rene.tar --name rene does create a single directory rene. with and without the --name option it is still one single directory -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
Hi, I've stumbled upon a situation in which fossil's latest wins merge strategy and a system's far-in-the-future clock have messed up my content timeline. I do recall fossil's warning regarding out-of-synch clocks when synching, but thought that it would DTRT since the files being modified in that system where unrelated to the files being modified in the server against which it was synching. I can live with the weird-looking timeline, but I'd like to get my content back. No amount of synching updating will get the file's contents to be the same in the filesystem as they are through the embedded doc link which means that I can't reapply the patch (since on the filesystem the file is OK), but I can't see it's content either (since fossil hides it from me, I assume because it consideres it merged). 'fossil changes' does not show any change. I can pinpoint the check-in manifest that consists of *only* the diff I'd like to re-apply, and the artifacts representing the file before and after the change, but I still don't know how to fix this. Is this expected? Any ideas? tks -- pica ___ 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] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
On Mon, Jul 18, 2011 at 6:41 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Hi, I've stumbled upon a situation in which fossil's latest wins merge strategy and a system's far-in-the-future clock have messed up my content timeline. I do recall fossil's warning regarding out-of-synch clocks when synching, but thought that it would DTRT since the files being modified in that system where unrelated to the files being modified in the server against which it was synching. I don't really understand your problem. I get the part about you having make some check-ins with far-in-the-future timestamps. But Fossil doesn't have a latest wins merge strategy. So I'm not sure where that is causing a problem. When you try to reference a check-in by its branch name, Fossil actually chooses the check-in of that branch with the latest timestamp. So, if you have some check-ins which are far in the future, those check-ins might be selected when you use the branch name, even though they are not the last check-ins in sequence. Is that what you are having problems with? (That has nothing to do with merging, though, which is why I don't really understand the problem.) If the previous paragraph does describe your problem, then the solution is to simply use a version hash or a tag for a specific version instead of the branch name. Another solution is to use the edit feature of the web interface to manually change the timestamps of the far-in-the-future check-ins to something more reasonable. If the second paragraph does not describe your problem, please try and restate your problem in different words, so that I can understand it. Tnx. I can live with the weird-looking timeline, but I'd like to get my content back. No amount of synching updating will get the file's contents to be the same in the filesystem as they are through the embedded doc link which means that I can't reapply the patch (since on the filesystem the file is OK), but I can't see it's content either (since fossil hides it from me, I assume because it consideres it merged). 'fossil changes' does not show any change. I can pinpoint the check-in manifest that consists of *only* the diff I'd like to re-apply, and the artifacts representing the file before and after the change, but I still don't know how to fix this. Is this expected? Any ideas? tks -- pica ___ 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] tar file is different then zip file
The old tar 'v7' format only supports file names up to 99 characters, according to the GNU tar documentation. The check in 'tar_add_header' (tar.c) checks for nName 100. The file name that gets mangled is exactly 100 chars long Gé On Mon, 18 Jul 2011, Rene wrote: On Mon, 18 Jul 2011 15:38:07 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 3:32 PM, Rene wrote: I have converted a cvs repo to fossil. I checked if the tag release_v5_1_0 would yield the same number of files as you can see from this timeline fragment it is version 186f4fdca4 [186f4fdca4] brokerhost geintroduceert * Upd mxflex/gbo/app_po.inc: 1.39 * Upd mxflex/gbo/app_bo.inc: 1.36 (user: renez, tags: trunk, release_v5_1_0) mxflex/gbo/app_bo.inc [diff] mxflex/gbo/app_po.inc [diff] The tar file contains 2 directories mxflex-186f4fdca41c087b(has 991 files) xflex-186f4fdca41c087b(has 2 files) while the zip file contains only one directory mxflex-186f4fdca41c087b(has 993 files) The tar file doesn't produce the release while the zip does. Perhaps the long filename support in tarball generator is busted. Do the two files that differ have very long pathnames? Are they the longest two pathnames in the repository? -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org [1] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users [2] xflex-186f4fdca41c087b has xflex-186f4fdca41c087b/mxflex/xbr_bus/general/gui/smarty/internals/core.assemble_plugin_filepath.php mxflex-186f4fdca41c087b has mxflex-186f4fdca41c087b/mxflex/xbr_bus/general/gui/smarty/internals/core.process_cached_inserts.php which is 1 shorter. If I do a tar bal from the head i get this in the top directory 22b79fe24110d d22b79fe24110d -ffd22b79fe24110d x-ffd22b79fe24110d 2b79fe24110d ex-ffd22b79fe24110d flex-ffd22b79fe24110d xflex-ffd22b79fe24110d 79fe24110d fd22b79fe24110d lex-ffd22b79fe24110d b79fe24110dffd22b79fe24110d mxflex-ffd22b79fe24110d while the zip just produces mxflex-ffd22b79fe24110d It seems how closer I come to the latest the more directories the tarbal creates. It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. -- Rene ___ 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] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
On Mon, Jul 18, 2011 at 6:52 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Jul 18, 2011 at 6:41 PM, Joan Picanyol i Puig wrote: I've stumbled upon a situation in which fossil's latest wins merge strategy and a system's far-in-the-future clock have messed up my If the second paragraph does not describe your problem, please try and restate your problem in different words, so that I can understand it. Tnx. I think what Joan is refering to is this, from the Fossil documentation: Wiki pages can branch and merge just like check-ins, though as of this writing (2008-07-29) there is no mechanism in the user interface to support branching and merging. The current implementation of the wiki shows the version of the wiki page that has the most recent timestamp. So I think that manually fixing the timestamps will correct the problem. ___ 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] The fossil service command
I'd say service is good. win-service may be appropriate since this command is valid only on Windows. However, I'd like to avoid use of hyphen (-) in commands. I hope this command is automatically disabled (via compiler or run-time) for non-windows platforms. - Original Message - From: Ron Wilson Sent: 07/19/11 04:03 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The fossil service command On Mon, Jul 18, 2011 at 4:52 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 18, 2011 at 10:51 PM, Richard Hipp d...@sqlite.org wrote: something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? i'd prefer win-service, but i don't use windows so i don't get a vote. win-service makes sense to me. I am in a mixed environment. or maybe: fossil M$ervice ;) *chuckle* ___ 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] The fossil service command
I currently host fossil server as a window service via NSSM. fossil service gets my vote. simple to the point. Other platforms could either re-direct it (e.g., fossil service becomes an alias for fossil server), or just print a message saying that the command is only valid for Windows operating systems. On Mon, Jul 18, 2011 at 8:47 PM, altufa...@mail.com wrote: I'd say service is good. win-service may be appropriate since this command is valid only on Windows. However, I'd like to avoid use of hyphen (-) in commands. I hope this command is automatically disabled (via compiler or run-time) for non-windows platforms. - Original Message - From: Ron Wilson Sent: 07/19/11 04:03 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The fossil service command On Mon, Jul 18, 2011 at 4:52 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 18, 2011 at 10:51 PM, Richard Hipp d...@sqlite.org wrote: something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? i'd prefer win-service, but i don't use windows so i don't get a vote. win-service makes sense to me. I am in a mixed environment. or maybe: fossil M$ervice ;) *chuckle* ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Converting from mercurial
Out of curiosity, why are you converting from mercurial? I ask because my friends and I adopted fossil and other friends of ours are asking us why we didn't go with mercurial instead. I didn't really have a good answer, apart from fossil seemed smaller (footprint, use-complexity) and cooler =) -jer On Mon, Jul 18, 2011 at 8:05 AM, Martin Gagnon eme...@gmail.com wrote: Le 2011-07-18 à 09:17, Lluís Batlle i Rossell virik...@gmail.com a écrit : Hello, As the lack of friendlyness I've always felt with git, before using fossil I used mercurial. If I wanted to convert any mercurial repository to fossil, how should do that? Has anyone done that? Regards, Lluís. Probably: hg -- git -- fossil Sorry, sent previous mail by mistake. -- Martin ___ 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] Converting from mercurial
On Mon, 18 Jul 2011 21:18:29 -0700 Jeremy Anderson jere...@gmail.com wrote: Out of curiosity, why are you converting from mercurial? While you weren't asking me, I converted from mercurial (and did the hg - git - fossil path) to fossil, so feel an answer from me isn't unreasonable. I ask because my friends and I adopted fossil and other friends of ours are asking us why we didn't go with mercurial instead. I didn't really have a good answer, apart from fossil seemed smaller (footprint, use-complexity) and cooler =) I'm an independent consultant, and often work for small companies that don't have a corporate SCM or issue tracking system, etc. I originally looked at fossil because I couldn't get a working build of mercurial on an antiquated solaris system (couldn't seem to get a Python build to use any of the ssl libraries, which broke hg even if you aren't using ssl). Getting a working fossil build on that system was easy - just turn off SSL in the Makefile. Once I had it up and working, investigating the wiki and issue tracking system was free, and turned out to be a real win. All for less work than setting up hg (or git) in the first place. Being able to have multiple checkouts of the same repository is also a win - I keep multiple branches checked out, and can merge differences without a push/pull, and can then push all of it to my clients machine. I still use hg for projects I release as open source, mostly because the major hosting sites (I prefer google code) don't support it. To make up for that, I plan to make adding fossil support to cabal as one of my next projects. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
