[fossil-users] Hierarchical tags in Embedded Documentation
Hi, is there anything new on this? is it possible to mark embedded documentation pages with hierarchical tags, like - fruit, banana and then list all pages that belong to the tags? If such feature is not present - may I ask to implement it? Thank you. ST ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] file renamed while open
Hi, all, i have just installed a fossil repo on a company-internal Linux server and i am seeing a weird new error message at the top of all pages: error code 28: file renamed while open: /.../bss-scripts.fsl It turns out that i am on an NFS (didn't know that until just now), and i know that NFS is a Bad Idea for repos, so i'm about to abandon this exercise, but wanted to get this on the record in case someone else searches for it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Hierarchical tags in Embedded Documentation
On Mon, Jul 15, 2013 at 1:37 PM, ST smn...@gmail.com wrote: Hi, is there anything new on this? Nope, but please don't take that personally. Feature requests are only implemented as time, energy, and desire of the developer(s) allow(s). Patches are of course welcomed :). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] file renamed while open
On Mon, Jul 15, 2013 at 7:39 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, i have just installed a fossil repo on a company-internal Linux server and i am seeing a weird new error message at the top of all pages: error code 28: file renamed while open: /.../bss-scripts.fsl This is a warning message that the SQLite core issues if the inode number of the database file changes. A change in the inode number can be an indicator that a database file has been renamed while it is in use, which can lead to database corruption. Or, it might just indicate that the database is on NFS. You'll be much much happier with the performance if you put the repository on a local filesystem, btw. It turns out that i am on an NFS (didn't know that until just now), and i know that NFS is a Bad Idea for repos, so i'm about to abandon this exercise, but wanted to get this on the record in case someone else searches for it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] file renamed while open
I have similar issue. It was running on Ubuntu local folder. I run all rebuild while the server still running. From there on I got the same message on the web interface. How do we fix this? Thanks. On Jul 15, 2013 8:09 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Jul 15, 2013 at 7:39 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, i have just installed a fossil repo on a company-internal Linux server and i am seeing a weird new error message at the top of all pages: error code 28: file renamed while open: /.../bss-scripts.fsl This is a warning message that the SQLite core issues if the inode number of the database file changes. A change in the inode number can be an indicator that a database file has been renamed while it is in use, which can lead to database corruption. Or, it might just indicate that the database is on NFS. You'll be much much happier with the performance if you put the repository on a local filesystem, btw. It turns out that i am on an NFS (didn't know that until just now), and i know that NFS is a Bad Idea for repos, so i'm about to abandon this exercise, but wanted to get this on the record in case someone else searches for it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] file renamed while open
On Mon, Jul 15, 2013 at 8:13 AM, Mohd Radzi Ibrahim imra...@gmail.comwrote: I have similar issue. It was running on Ubuntu local folder. I run all rebuild while the server still running. From there on I got the same message on the web interface. How do we fix this? Can you describe how to reproduce the problem? -- 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] file renamed while open
On Jul 15, 2013 8:17 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Jul 15, 2013 at 8:13 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: I have similar issue. It was running on Ubuntu local folder. I run all rebuild while the server still running. From there on I got the same message on the web interface. How do we fix this? Can you describe how to reproduce the problem? After update to the latest (I think it was one month ago or so), I run fossil all rebuild while the fossil daemon is running. 1. fossil update 2. make; sudo make install 3. fossil all rebuild Btw. I am running ubuntu 13.04. Thanks. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] file renamed while open
On Mon, Jul 15, 2013 at 2:08 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Jul 15, 2013 at 7:39 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, i have just installed a fossil repo on a company-internal Linux server and i am seeing a weird new error message at the top of all pages: error code 28: file renamed while open: /.../bss-scripts.fsl This is a warning message that the SQLite core issues if the inode number of the database file changes. A change in the inode number can be an indicator that a database file has been renamed while it is in use, which can lead to database corruption. Or, it might just indicate that the database is on NFS. You'll be much much happier with the performance if you put the repository on a local filesystem, btw. i would rather gnaw off my foot than hassle with having a DB on an NFS, i just wasn't aware until after the fact that i was even on NFS :/. So, problem solved by simply moving the repo file into the local FS. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] file renamed while open
On Mon, Jul 15, 2013 at 8:23 AM, Mohd Radzi Ibrahim imra...@gmail.comwrote: After update to the latest (I think it was one month ago or so), I run fossil all rebuild while the fossil daemon is running. 1. fossil update 2. make; sudo make install 3. fossil all rebuild I'm not sure what the fossil daemon is. So I tried running fossil ui in one shell while running fossil all rebuild in another. I took care to click on the web interface and bring up various pages while the repo was being rebuilt. I get no errors and no warnings in either the fossil all rebuild or in the web interface. This is on ubuntu. -- 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] Diff doesn't appear correct with incremental import
This all works fine, with one significant exception. When I do a diff operation on many files that are updated during the incremental import, it appears that the entire file is new. In other words, the left hand side of the diff is blank and the right hand side is entirely green. If I do a unified diff, the entire screen is green. I look at the patch, and it's filed with plus signs. Etc. Just wondering if anyone else had ideas about this issue. Perhaps I'm not interpreting the meaning of incremental properly? I checked the src/import.c code in the fossil repository but will need to do a little more digging to really understand what's going on (need to study up on fossil repository structure, etc). Any guidance or impressions would be greatly appreciated. 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] file renamed while open
I don't think NFS should be a problem. I am involved in an installation using fossil on NFS with over 300 fossils synced between 3 sites. Some 300 users have access but I'm not sure how many are actively accessing the repos. All fossils are accessed via NFS so collisions happen all the time. People know to just try again on the occasional update fail due to a busy fossil. A more graceful fail or better yet a wait and retry would be nice but recovery is as simple as up-arrow, enter. Fossil isn't perfect (I'd love to see fossil mv behave the same as Unix mv) but NFS has generally not been an issue. I'v not seen this error and it might be either a regression or new issue. In short, I think fossil usually works fine on NFS. The caveat might be *which* NFS. We see different NFS issues with sqlite3 locking depending on what tier or vendor your server is. Aside: on my home system I use fossil on MooseFS which has worse locking than NFS. Performance is slower than running on local disk but still in the sub second range for most operations. So long as you don't access the fossil file simultaneously from two different hosts there are no locking or crashing issues that I've seen. This is all with version 1.25. On Mon, Jul 15, 2013 at 5:27 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 15, 2013 at 2:08 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Jul 15, 2013 at 7:39 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, i have just installed a fossil repo on a company-internal Linux server and i am seeing a weird new error message at the top of all pages: error code 28: file renamed while open: /.../bss-scripts.fsl This is a warning message that the SQLite core issues if the inode number of the database file changes. A change in the inode number can be an indicator that a database file has been renamed while it is in use, which can lead to database corruption. Or, it might just indicate that the database is on NFS. You'll be much much happier with the performance if you put the repository on a local filesystem, btw. i would rather gnaw off my foot than hassle with having a DB on an NFS, i just wasn't aware until after the fact that i was even on NFS :/. So, problem solved by simply moving the repo file into the local FS. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] file renamed while open
On Mon, Jul 15, 2013 at 5:38 PM, Matt Welland estifo...@gmail.com wrote: ...know to just try again on the occasional update fail due to a busy fossil. A more graceful fail or better yet a wait and retry would be nice but recovery is as simple as up-arrow, enter. i've been bitten by NFS-related deficiencies enough times that i try to stay away from NFS if i can (nothing to do with sqlite3 - completely other problems, most of which were so long ago that they have certainly been resolved in the mean time). Had i realized that our new www dir was on an NFS i wouldn't have tried placing fossil there in the first place. Actually, i'm glad the problem showed up immediately - that certainly saved me time compared to me having to track down the problem later (but it worked yesterday...). Fossil isn't perfect (I'd love to see fossil mv behave the same as Unix mv) but NFS has generally not been an issue. I'v not seen this error and it might be either a regression or new issue. It was the first time i saw it, but it didn't occur to me to check if i was on NFS until i was halfway done posting. In short, I think fossil usually works fine on NFS. The caveat might be *which* NFS. We see different NFS issues with sqlite3 locking depending on what tier or vendor your server is. Since i'm the one who'll have to end up dealing with the support requests, i went for the approach which moved the .fsl file out of the NFS ;). Aside: on my home system I use fossil on MooseFS which has worse locking than NFS. Performance is slower than running on local disk but still in the sub second range for most operations. So long as you don't access the fossil file simultaneously from two different hosts there are no locking or crashing issues that I've seen. This is all with version 1.25. You haven't convinced me - i'm still nervous around NFS ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] file renamed while open
On Mon, Jul 15, 2013 at 8:50 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 15, 2013 at 5:38 PM, Matt Welland estifo...@gmail.com wrote: ...know to just try again on the occasional update fail due to a busy fossil. A more graceful fail or better yet a wait and retry would be nice but recovery is as simple as up-arrow, enter. i've been bitten by NFS-related deficiencies enough times that i try to stay away from NFS if i can (nothing to do with sqlite3 - completely other problems, most of which were so long ago that they have certainly been resolved in the mean time). Had i realized that our new www dir was on an NFS i wouldn't have tried placing fossil there in the first place. Actually, i'm glad the problem showed up immediately - that certainly saved me time compared to me having to track down the problem later (but it worked yesterday...). My concern is that if the answer to all network based filesystem issues is use local disk then that may unnecessarily turn people away. If this is a real bug (and it sounds like it may be) then those of us forced to work on NFS etc. would benefit from it being fixed before the next official release. Fossil isn't perfect (I'd love to see fossil mv behave the same as Unix mv) but NFS has generally not been an issue. I'v not seen this error and it might be either a regression or new issue. It was the first time i saw it, but it didn't occur to me to check if i was on NFS until i was halfway done posting. In short, I think fossil usually works fine on NFS. The caveat might be *which* NFS. We see different NFS issues with sqlite3 locking depending on what tier or vendor your server is. Since i'm the one who'll have to end up dealing with the support requests, i went for the approach which moved the .fsl file out of the NFS ;). You are fortunate to have that luxury :) Aside: on my home system I use fossil on MooseFS which has worse locking than NFS. Performance is slower than running on local disk but still in the sub second range for most operations. So long as you don't access the fossil file simultaneously from two different hosts there are no locking or crashing issues that I've seen. This is all with version 1.25. You haven't convinced me - i'm still nervous around NFS ;). As well you should be. NFS can be a challenge but it is also very convenient. I hope the fossil developers are open to some level of support to using fossil on networked file systems. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Ssh and multiple users on the same ssh account
On 2013-07-15 02:34, David Mason wrote: You might want to look at how mercurial-server works. You set up one remote account that owns the master repository, but then everyone can access e.g. ssh://h...@foo.bar/reponame but each key has a command set up that says who it is that's accessing and then it uses the rules to control what the person can do. The clever thing is that there is a special hgadmin repository that has keys and an access.conf file that essentially says which keys can do what to which repos. So that whoever has write access to the hgadmin repo can edit the access.conf and add/remove keys and then on the push, it creates the authorized_keys that enforces the security/permission model http://www.lshift.net/mercurial-server.html ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Thanks, I thought of something like that to. -- 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] file renamed while open
On Mon, Jul 15, 2013 at 12:23 PM, Matt Welland estifo...@gmail.com wrote: On Mon, Jul 15, 2013 at 8:50 AM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Jul 15, 2013 at 5:38 PM, Matt Welland estifo...@gmail.comwrote: ...know to just try again on the occasional update fail due to a busy fossil. A more graceful fail or better yet a wait and retry would be nice but recovery is as simple as up-arrow, enter. i've been bitten by NFS-related deficiencies enough times that i try to stay away from NFS if i can (nothing to do with sqlite3 - completely other problems, most of which were so long ago that they have certainly been resolved in the mean time). Had i realized that our new www dir was on an NFS i wouldn't have tried placing fossil there in the first place. Actually, i'm glad the problem showed up immediately - that certainly saved me time compared to me having to track down the problem later (but it worked yesterday...). My concern is that if the answer to all network based filesystem issues is use local disk then that may unnecessarily turn people away. If this is a real bug (and it sounds like it may be) then those of us forced to work on NFS etc. would benefit from it being fixed before the next official release. The bug is in NFS, not in SQLite or Fossil. A well-configured NFS system will support both SQLite and Fossil without correctness problems. (NFS will be slower than a local filesystem, but that is not a problem that is unique to SQLite or Fossil - NFS is just slower.) The issue is that it can be tricky to set up NFS correctly and many NFS installations are not set up correctly. They *appear* to work most of the time, but there are problems that some programs (such as SQLite) might stumble over. If you set an environment variable export FOSSIL_VFS=unix-dotfile Then SQLite will use dot-file locking rather than posix advisory locking. This will make it more robust around dodgy NFS implementation. But it will also be a little slower (though you don't really care about performance if you are using NFS, right?) and if something crashes, it might leave behind some lock files (actually directories) that need to be manually removed. Also, beware: All uses of the repository must use the same locking protocol or else you could run into trouble. In other words, if you change FOSSIL_VFS to unix-dotfile make sure you do it everywhere. -- 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] Diff doesn't appear correct with incremental import
On Mon, Jul 15, 2013 at 3:21 PM, Sean Woods s...@seanwoods.com wrote: This all works fine, with one significant exception. When I do a diff operation on many files that are updated during the incremental import, it appears that the entire file is new. In other words, the left hand side of the diff is blank and the right hand side is entirely green. If I do a unified diff, the entire screen is green. I look at the patch, and it's filed with plus signs. Etc. Just wondering if anyone else had ideas about this issue. Perhaps I'm not interpreting the meaning of incremental properly? I checked the src/import.c code in the fossil repository but will need to do a little more digging to really understand what's going on (need to study up on fossil repository structure, etc). Any guidance or impressions would be greatly appreciated. I've been patching the import code on my little spare time and, from what I've seen, I'm under the impression that incremental import is not supported. So, I believe that the --incremental option of the import command is a bit misleading. The only thing it does is to open an existing SQLite database without complaining. The problem with incremental imports is the SHA1 hash mapping between git and Fossil: in the pure content case (blobs) they may be the same, but the correspondence between git commits and manifest artifacts is not currently saved anywhere. I don't think it should be too much difficult to do though, because every other version control system does it. If you have some patience, I may take a look at it once I finish testing my import patches that generate delta manifests. Regards. -- Isaac Jurado The noblest pleasure is the joy of understanding Leonardo da Vinci ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Alias for first initial empty checkin?
Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] ? -bch -- Brad Harder Method Logic Digital Consulting http://twitter.com/bcharder ___ 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] Alias for first initial empty checkin?
On Tue, Jul 16, 2013 at 12:21 AM, B Harder brad.har...@gmail.com wrote: Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] There is a way to do it but you have to know the timeframe when the repo was started, e.g.: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' === 2007-07-21 === 14:10:57 [dbda8d6ce9] Initial check-in of m1 sources. (user: drh tags: trunk) 14:09:59 [a28c83647d] initial empty baseline (user: drh tags: trunk) interestingly, the above fails if i enter 14:10:00 as the time, though the first commit happened 1 second before that, but let's just call that a rare corner case and ignore it ;). (No, i didn't know the time of the first commit - i had to go search for it ;) So we end up with this: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' | tail -1 | cut -d'[' -f2 | cut -d']' -f1 a28c83647d or: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' | tail -1 | cut -d' ' -f2 [a28c83647d] depending on what format you want. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Alias for first initial empty checkin?
On Tue, Jul 16, 2013 at 12:53 AM, Stephan Beal sgb...@googlemail.comwrote: === 2007-07-21 === 14:10:57 [dbda8d6ce9] Initial check-in of m1 sources. (user: drh tags: trunk) 14:09:59 [a28c83647d] initial empty baseline (user: drh tags: trunk) PS: fossil turns 6 next week! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Alias for first initial empty checkin?
On 7/15/13, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 16, 2013 at 12:21 AM, B Harder brad.har...@gmail.com wrote: Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] There is a way to do it but you have to know the timeframe when the repo was started, e.g.: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' === 2007-07-21 === 14:10:57 [dbda8d6ce9] Initial check-in of m1 sources. (user: drh tags: trunk) 14:09:59 [a28c83647d] initial empty baseline (user: drh tags: trunk) I'm using this to make (eg) vendor branches that I don't want to remain pure (ie: not related to history of whatever current branch I'm on). Do other people do this? Is there a call for giving the initial commit a non-sticky ci0 tag or such? -bch interestingly, the above fails if i enter 14:10:00 as the time, though the first commit happened 1 second before that, but let's just call that a rare corner case and ignore it ;). (No, i didn't know the time of the first commit - i had to go search for it ;) So we end up with this: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' | tail -1 | cut -d'[' -f2 | cut -d']' -f1 a28c83647d or: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' | tail -1 | cut -d' ' -f2 [a28c83647d] depending on what format you want. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] Alias for first initial empty checkin?
** s/don't want to remain pure/want to remain pure/. On 7/15/13, B Harder brad.har...@gmail.com wrote: On 7/15/13, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 16, 2013 at 12:21 AM, B Harder brad.har...@gmail.com wrote: Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] There is a way to do it but you have to know the timeframe when the repo was started, e.g.: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' === 2007-07-21 === 14:10:57 [dbda8d6ce9] Initial check-in of m1 sources. (user: drh tags: trunk) 14:09:59 [a28c83647d] initial empty baseline (user: drh tags: trunk) I'm using this to make (eg) vendor branches that I don't want to remain pure (ie: not related to history of whatever current branch I'm on). Do other people do this? Is there a call for giving the initial commit a non-sticky ci0 tag or such? -bch interestingly, the above fails if i enter 14:10:00 as the time, though the first commit happened 1 second before that, but let's just call that a rare corner case and ignore it ;). (No, i didn't know the time of the first commit - i had to go search for it ;) So we end up with this: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' | tail -1 | cut -d'[' -f2 | cut -d']' -f1 a28c83647d or: stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' | tail -1 | cut -d' ' -f2 [a28c83647d] depending on what format you want. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] Alias for first initial empty checkin?
Le 15 juil. 2013 18:21, B Harder brad.har...@gmail.com a écrit : Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] ? You can tag the initial commit if it's important for you. So you just have the trouble to seek for the sha1 code once. -- Martin G. ___ 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] Alias for first initial empty checkin?
On Mon, Jul 15, 2013 at 03:21:54PM -0700, B Harder wrote: Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] ? -bch I got it.. what you want is: fossil up root:trunk The prefix root: will get the root a of branch.. the root of the trunk is the initial check-in.. -- Martin G. ___ 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] Alias for first initial empty checkin?
On 7/15/13, Martin Gagnon eme...@gmail.com wrote: Le 15 juil. 2013 18:21, B Harder brad.har...@gmail.com a écrit : Is there a: $ fossil co initial_ci Command/workalike available, or am I left to: $ fossil timel -n | tail [copy SHA1] $ fossil co [paste SHA1] ? You can tag the initial commit if it's important for you. So you just have the trouble to seek for the sha1 code once. You're right. :) -bch -- Martin G. -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
