Re: [fossil-users] committing to a *new* branch from a closed branch not currently possible?

Personally I see limited usefulness in closing a leaf. It is branches that need to be closed (albeit by closing a leaf). I'll let the developers that are requesting this know that it ain't gonna happen. As was suggested they can open/re-close the node as needed. On Fri, Jul 18, 2014 at 12:09 PM,

Re: [fossil-users] 'open --nested', quick poll

NOTE: In Unix there is the handy shortcut that you can leave off the target location: ln -s foo/bar will create the link: bar -> foo/bar Quite handy and yet another reason for the parameter ordering used on Linux/Unix. On Tue, Jul 22, 2014 at 9:46 AM, Warren Young wrote: > On 7/22/2014 10:4

Re: [fossil-users] 'open --nested', quick poll

We are using -nested very successfully to break a large area of related but mostly independent sub-areas into multiple fossils. I'm very happy with it. BTW, the whole reason why the modern SCM approach used by fossil, git etc. is so powerful is because the number of degrees of freedom were reduced

[fossil-users] Fossil does not handle this (ugly) scenario gracefully

A fossil user accidentally created a file where he intended to create a directory. After correcting his mistake he was completely unable to commit. To repair this I moved his changes to a branch and recreated them correctly. I think fossil should handle this by disallowing a file to become a direct

Re: [fossil-users] syncing many repositories

Using rsync, make and some smart log file processing using logpro I was able to bidirectionally sync over 250 fossils every two minutes between three sites. It worked very well for two years and then we switched to all sites using ssh. If details on this would be useful let me know and I'll write i

Re: [fossil-users] Asciidoc(tor) & Fossil

On Thu, Aug 14, 2014 at 3:39 AM, Stephan Beal wrote: > On Thu, Aug 14, 2014 at 12:24 PM, Gour wrote: > >> https://github.com/srackham/asciidoc-fossil-backend which says: >> "https://github.com/srackham/asciidoc-fossil-backend"; >> > > Sorry, i missed that part. i'm glad to see someone gets some

Re: [fossil-users] More on Fossil-v-Git

On Fri, Sep 5, 2014 at 12:10 PM, Ron W wrote: > On Fri, Sep 5, 2014 at 12:57 PM, Gour wrote: > >> I use lto-2 tapes, but the point is that Fossil keeps project's history >> since the very beginning. :-) > > > Still need to keep the Fossil repo backed up. > Is there really a need for a backup i

Re: [fossil-users] How to do branching with new major versions

On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp wrote: > Sometimes we will make a check-in to trunk then later decide it doesn't > belong there, so then move it into a branch. ( Isn't this only possible if no further commits have been made on the trunk? I suppose one possible "fix" if there have

Re: [fossil-users] How to do branching with new major versions

On Wed, Sep 10, 2014 at 8:47 PM, Richard Hipp wrote: > > > On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland > wrote: > >> >> On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp wrote: >> >>> Sometimes we will make a check-in to trunk then later decide it does

Re: [fossil-users] auto-sync before merge?

I've been mildly bitten by this behavior before. When merging from a branch a warning that you haven't sync'd would be a nice to have. Autosync prior to merge would work for me but the warning would be a decent alternative. On Thu, Oct 9, 2014 at 12:43 PM, Richard Hipp wrote: > I just did a "fos

Re: [fossil-users] auto-sync before merge?

On Fri, Oct 10, 2014 at 8:01 PM, Stephan Beal wrote: > On Fri, Oct 10, 2014 at 10:10 PM, Ross Berteig > wrote: > >> Personally, I wouldn't expect that at all. The "fossil merge" command >> edits the currently open workspace based ... >> > > +1 > > >> The "fossil update" command on the other hand

Re: [fossil-users] proposed patch: symlinks appear as regular files even when allow-symlinks is on

Since you all are looking at symlinks someone reported to me that there are problems when a symlink is replaced with a directory or vice versa. Here is the script that he generated to illustrate the issue: ## Create repo and initial population fossil init bare.repo mkdir link_target_dir touch li

[fossil-users] Symlinks issue, replacing a symlink with a directory breaks fossil update

(I posted this initially to the "symlinks appear as regular files" thread, reposting as new thread). Someone reported to me that there are problems when a symlink is replaced with a directory or vice versa. Here is the script that he generated to illustrate the issue: ## Create repo and initial

Re: [fossil-users] [Suggestion] Branch descriptions

+1 IMHO this is a good idea. How technically feasible it is I have no idea. On Jan 4, 2015 10:59 AM, "Philip Bennefall" wrote: > Hi all, > > I have a quick suggestion to present. While browsing the SqLite timeline, > it struck me that I don't know what a lot of the branches are and I have no > ob

Re: [fossil-users] fixing "db locked" error

If an sqlite3 db gets locked on NFS the "fix" is to copy the file to a tmp dir and copy dump it: mkdir tmp cp foo.fossil* tmp rm foo.fossil* sqlite3 tmp/foo.fossil .dump | sqlite3 foo.fossil This deals gracefully with cases where there is a .journal file, locks and other problems. Just my $0.02

Re: [fossil-users] Fossil 2.0 (reprise)

I really like the new look and the new features. It looks like it is almost time to qualify the new version and upgrade! A couple comments: 1. Under tickets it was initially non-obvious to me to click on reports to see more tickets. It might be nice to list the first 4 or so report types on the ti

Re: [fossil-users] Fossil 2.0 (reprise)

On Feb 18, 2015 11:47 PM, "Warren Young" wrote: > > On Feb 18, 2015, at 11:04 PM, Andy Bradford wrote: > > > > I prefer monospaced fonts for most things that I do with text. > > We have hundreds of years of evidence that it is easier to read prose in a proportional font than in a monospace font.

Re: [fossil-users] does fossil rstats exist?

On Feb 21, 2015 1:34 PM, "jungle Boogie" wrote: > > Hello All, > > Came across this docs page today: > http://www.fossil-scm.org/index.html/doc/2010-01-01/www/reference.wiki > > It references something I've never heard of, rstats: > Deliver a report of the repository statistics for the > cur

Re: [fossil-users] does fossil rstats exist?

On Feb 21, 2015 6:23 PM, "jungle Boogie" wrote: > > Hi Matt, > On 21 February 2015 at 14:50, Matt Welland wrote: > >> Secondly, can you check out a specific file on a repo if you give a > >> path? I knwo checkout but that requires a version number. > >

[fossil-users] Wishlist: Interface to technotes from command line

Technotes might be useful for automation. For example automated build sysmtems could post a technote when the build completes and passes validation. Just my $0.02 ... -- Matt -=- The moment we want to believe something, we suddenly see all the arguments for it, and become blind to the arguments

Re: [fossil-users] Wishlist: Interface to technotes from command line

ously. Once I started doing this my RSI issues went away. On Sun, Feb 22, 2015 at 8:16 AM, Stephan Beal wrote: > On Sun, Feb 22, 2015 at 4:10 PM, Matt Welland wrote: > >> Technotes might be useful for automation. For example automated build >> sysmtems could post a technote when

Re: [fossil-users] For your dscm-politik reading pleasure

On Mon, Mar 2, 2015 at 11:46 AM, bch wrote: > Renames as first-class dscm operations: > > http://www.markshuttleworth.com/archives/123 > The basic point made in the post by Mark Shuttleworth (in 2007 BTW) is a good one. Cleaning up or refactoring is hard to do and ideally an SCM tool helps the

Re: [fossil-users] For your dscm-politik reading pleasure

On Mon, Mar 2, 2015 at 1:37 PM, jungle Boogie wrote: > Hi Matt, > On 2 March 2015 at 12:14, Matt Welland wrote: > > The basic point made in the post by Mark Shuttleworth (in 2007 BTW) is a > > good one. > > > > Cleaning up or refactoring is hard to do and i

Re: [fossil-users] New timeline display options

+1 circular nodes, +1 colored lines, seemed to make visually tracking the branch easier to my eyes. but as Brad said, a matter of style. On Mon, Mar 30, 2015 at 2:22 PM, bch wrote: > +1 circular "nodes", -1 colored lines, as a matter of style, imo. > Really nice work, though! > > -bch > > > On

Re: [fossil-users] New timeline display options

On Tue, Mar 31, 2015 at 9:20 AM, Andy Bradford wrote: > Thus said Matt Welland on Mon, 30 Mar 2015 21:08:49 -0700: > > > +1 circular nodes, +1 colored lines, seemed to make visually tracking > > the branch easier to my eyes. but as Brad said, a matter of style. > > Defin

Re: [fossil-users] New timeline display options

ual hint as to which is which branch. Just my $0.02 ... > > -bch > > > On 3/31/15, Matt Welland wrote: > > On Tue, Mar 31, 2015 at 9:20 AM, Andy Bradford > > > wrote: > > > >> Thus said Matt Welland on Mon, 30 Mar 2015 21:08:49 -0700: > >>

Re: [fossil-users] Introducing Lagerstatte, an open-source hosting service for Fossil repositories

On Mon, Mar 30, 2015 at 10:57 PM, Vikrant Chaudhary wrote: > fossil clone --cheap file:///path/to/upstream.fossil new-project.fossil > +1 I think I would use this feature should it ever come available. I have 500M+ repos where a cheap clone would be quite nice to have. I assume the feature woul

Re: [fossil-users] Introducing Lagerstatte, an open-source hosting service for Fossil repositories

On Wed, Apr 1, 2015 at 6:55 PM, Andy Goth wrote: > On 4/1/2015 3:21 AM, Vikrant Chaudhary wrote: > >> I'm thinking about how this could be used at my workplace. On some > >> projects we have shared computers called viewservers ("view" being a > >> ClearCase term) on which we create our sandboxes

Re: [fossil-users] Two trunks?

On Fri, Apr 3, 2015 at 6:11 AM, Richard Hipp wrote: > On 4/3/15, Sean Woods wrote: > > On Fri, Apr 3, 2015, at 08:25 AM, Richard Hipp wrote: > >> On 4/3/15, Sean Woods wrote: > >> > > >> > How can I "merge" both of these "branches" back into one trunk? > >> > >> "fossil merge" (with no argumen

Re: [fossil-users] Two trunks?

ep rm and mv. In a perfect universe Fossil would have a non-distributed mode for those of us trying to use it in a corporate setting and a Unix mode where the constraints of Microsoft Windows could be ignored :) > > From: Matt Welland > It would be very cool if on update if a fork was dete

Re: [fossil-users] Two trunks?

On Sun, Apr 5, 2015 at 12:48 PM, Joerg Sonnenberger wrote: > On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote: > > The auto fork merge is the same as the automatic merge that one of the > fork > > creators would have experienced if they had done their commit a few &

Re: [fossil-users] Two trunks?

On Sun, Apr 5, 2015 at 2:13 PM, Joerg Sonnenberger wrote: > On Sun, Apr 05, 2015 at 01:56:06PM -0700, Matt Welland wrote: > > On Sun, Apr 5, 2015 at 12:48 PM, Joerg Sonnenberger < > jo...@britannica.bec.de > > > wrote: > > > > > On Sun, Apr 05, 2015

Re: [fossil-users] Two trunks?

On Mon, Apr 6, 2015 at 2:53 AM, Joerg Sonnenberger wrote: > On Sun, Apr 05, 2015 at 02:59:27PM -0700, Matt Welland wrote: > > I understand (mostly) why git > > doesn't have this problem, it makes no pretense about being centralized > and > > it doesn't allow

Re: [fossil-users] Two trunks?

On Mon, Apr 6, 2015 at 10:05 AM, James Moger wrote: > I thought forks were blocked by the push in git. What scenario can lead to >> dual heads in git? >> > > By default non-fast-forward pushes (fork in Fossil terms) are blocked. > This is what I thought. So what technical obstacles are there pre

Re: [fossil-users] Two trunks?

On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford wrote: > Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200: > > > If they can happen when two people push to central repository one > > after another, then IMHO they should be blocked. Or at least there > > should be a possibilit

Re: [fossil-users] Two trunks?

On Wed, Apr 8, 2015 at 6:16 AM, Richard Hipp wrote: > On 4/8/15, Matt Welland wrote: > > Today I got to hear from a team that had a very near serious QA escape > due > > to an undetected fork. > > Can you provide more detail on this incident so that I can better > un

Re: [fossil-users] Two trunks?

This is the timeline from that repo. If there is data to sync and you are in the 0b2ff node then you get the double WARNING. [image: Inline image 1] On Wed, Apr 8, 2015 at 11:01 PM, Andy Bradford wrote: > Thus said Matt Welland on Wed, 08 Apr 2015 22:39:36 -0700: > > > >

Re: [fossil-users] Two trunks?

On Wed, Apr 8, 2015 at 9:39 PM, Andy Bradford wrote: > Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700: > > > matt@xena:/tmp/testing$ fossil sync > > Sync with file:///home/matt/fossils/blah.fossil > > Round-trips: 1 Artifacts sent: 4 received: 0 > >

Re: [fossil-users] Two trunks?

On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford wrote: > Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700: > > > What we are seeing is that forks happen due to simultaneous, partially > > overlapping, commits and that neither party involved in the two > > c

Re: [fossil-users] Two trunks?

On Thu, Apr 9, 2015 at 7:43 AM, Andy Bradford wrote: > Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700: > > > Would it be possible to detect and warn on update, status and push? > > What about pull?? > > E.g. if I pull in new content that creates a fork s

Re: [fossil-users] Two trunks?

Does fork notification really warrant another setting? If there is a fork on some other branch either fix by merging it or rename one of the legs. There is no sensible need for a fork to exist in a timeline that I can think of. Forks are rare in most repos (the intensely busy repos I deal with seem

Re: [fossil-users] Two trunks?

On Mon, Apr 13, 2015 at 1:59 AM, Jan Nijtmans wrote: > 2015-04-13 6:31 GMT+02:00 Andy Bradford : > >> It's not yet merged to trunk, but I have borrowed from Jan's work and >> merged into the sync-forkwarn branch for what I think will provide a >> better experience (e.g. almost no false pos

Re: [fossil-users] Two trunks?

In short, if there are no false positive notifications on forks the fallout from this change should really be very minimal and the benefits for those who need it are substantial. The long-winded response: Mark Twain said it well, “I've lived through some terrible things in my life, some of which

Re: [fossil-users] Two trunks?

On Thu, Apr 16, 2015 at 1:38 AM, Jan Nijtmans wrote: > 2015-04-14 21:11 GMT+02:00 Andy Bradford: > > Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200: > >> Maybe more valuable would be to adapt the /leaves page, so people > >> searching forks have an easy way to do so. > > > > I pro

Re: [fossil-users] Two trunks?

On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans wrote: > 2015-04-16 13:44 GMT+02:00 Matt Welland : > > I'm confused by this. If the fork was merged to trunk it is no longer a > fork > > and should not be detected. Can you elaborate? > > In fossil it is possible to

Re: [fossil-users] Two trunks?

On Thu, Apr 16, 2015 at 1:22 PM, Ron W wrote: > On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland > wrote: > >> Since these are effectively forks that have been resolved by merging is >> it possible to detect them as such and not report them? >> > > I think t

Re: [fossil-users] Two trunks?

On Fri, Apr 17, 2015 at 10:12 AM, Ron W wrote: > On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger < > jo...@britannica.bec.de> wrote: > >> As discussed earlier, a fork means more than one >> leaf for the same branch. > > > And merging the leaf of a branch to another branch (maybe trunk) does n

Re: [fossil-users] Two trunks?

source of forks that I'm seeing. Disconnected users would sync in commits as before, potentially creating forks. The warning on fork detection code would still be needed. On Sat, Apr 18, 2015 at 4:14 AM, Matt Welland wrote: > > > On Fri, Apr 17, 2015 at 10:12 AM, Ron W wrote: &g

Re: [fossil-users] Two trunks?

ompletes push a # commit from b completes push b On Sat, Apr 18, 2015 at 1:16 PM, Scott Robison wrote: > On Sat, Apr 18, 2015 at 12:19 PM, Ron W wrote: > >> On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland >> wrote: >> >>> >>> >> #3 was look

Re: [fossil-users] Two trunks?

If a fork happens, merge it, change it into a branch or close it. There is no need for a forks page. All that is needed is to keep developers informed so the fork doesn't lie undetected and cause confusion. On Apr 25, 2015 11:35 AM, "jungle Boogie" wrote: > On 25 April 2015 at 09:18, Andy Bradf

Re: [fossil-users] Two trunks?

On Sat, Apr 25, 2015 at 1:48 PM, Richard Hipp wrote: > On 4/25/15, Matt Welland wrote: > > There is no need for a forks page. All that is needed is to keep > developers > > informed ... > > To my ears, those two sentences directly contradict one another. > > Th

Re: [fossil-users] Testing. Was: Two trunks?

bf6ca looks very much like a potential accidentally orphaned commit. Did mistachkin commit his changes thinking they were on the branch branch-3.7.16 and part of the merge that led to sessions? Maybe, maybe not. The commit should be inspected and either merged, closed or named to a different branch

Re: [fossil-users] Two trunks?

On Apr 25, 2015 8:57 PM, "Ron W" wrote: > > On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland wrote: >> >> The expectation is that if a commit succeeds *it is a part of the series of commits on that branch*. This expectation is valid in git, it is valid in subversion, i

Re: [fossil-users] Two trunks?

On Sat, Apr 25, 2015 at 9:50 PM, Andy Bradford wrote: > Thus said Matt Welland on Sat, 25 Apr 2015 15:05:54 -0700: > > > Our preferred work style is to get feedback from the command line > > where possible. If notified of a fork during update, sync or commit a > >

Re: [fossil-users] Two trunks?

On Sat, Apr 25, 2015 at 10:20 PM, Ron W wrote: > On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland > wrote: > >> A fork is seen as a failure of fossil to handle a commit that requires >> tiresome manual intervention to fix. >> > > But, doesn't a blocked merg

Re: [fossil-users] Testing. Was: Two trunks?

I like this idea. I will test this branch Monday. +1 On Sun, Apr 26, 2015 at 10:16 AM, Jan Nijtmans wrote: > 2015-04-26 12:54 GMT+02:00 Richard Hipp : > > Yes, but it is not a fork. And so we shouldn't call it "fossil forks" > > since that would prevent us from creating a "fossil forks" comman

Re: [fossil-users] Feature idea: Protected branches

On Mon, May 11, 2015 at 2:17 PM, Warren Young wrote: > On May 11, 2015, at 10:48 AM, Andy Goth wrote: > > > > X group manages Y branch. > > Didn’t we all learn how to share in kindergarten? > > If it makes sense for multiple groups with disparate interests to all be > working on a single common

Re: [fossil-users] Feature idea: Protected branches

On Tue, May 12, 2015 at 1:51 PM, Warren Young wrote: > On May 12, 2015, at 2:31 PM, Matt Welland wrote: > > > > Does your team use Unix file permissions to prevent people from viewing > files they have no right to be looking at? > > Are you suggesting that Fossil

Re: [fossil-users] trunk closed??

This is an exceedingly confusing behavior from fossil but the fix is easy. Just do "fossil up trunk". On Thu, May 28, 2015 at 11:36 AM, Richard Hipp wrote: > On 5/28/15, jungle Boogie wrote: > > Hello All, > > > > I follow and update from trunk pretty regularly...this is how I notice > > those

Re: [fossil-users] trunk closed??

n regarding attached nodes on a DAG. In short a very loud warning is needed, no matter what path you take. Just my $0.02. On Fri, May 29, 2015 at 9:05 AM, j. van den hoff wrote: > On Fri, 29 May 2015 17:38:39 +0200, Richard Hipp wrote: > > On 5/29/15, Matt Welland wrote: >> &

Re: [fossil-users] Irrecoverable repository inconsistency between local and remote, after an assertion failure on Windows.

Another thing to try if you haven't already done so is to rebuild repos at both ends. I've seen this fix weird sync errors a couple times. On Wed, Jun 3, 2015 at 6:12 PM, Andy Bradford wrote: > Thus said "Ardie H. Hwang" on Thu, 04 Jun 2015 06:01:15 +0900: > > > Clearly, server does not know the

Re: [fossil-users] SQLITE_BUSY ?

We see these (or similar) occasionally when the filesystem gets slow. The problem is exacerbated with large repos. On Mon, Jun 15, 2015 at 1:41 PM, bch wrote: > I've occasionally (rarely) seen errors like the following -- anybody > have an idea what might be going on ? Anything I can do to help

[fossil-users] clones taking 2x (or more?) time due to "extra delta compression"

but I don't see any way to turn it off. also it looks like fossil has low tolerance for parallel running "open" process. I guess I naively assumed that since sqlite3 is mostly ACID compliant that parallel opening of fossils would be supported. I'm adding locking as a work-around but would the deve

Re: [fossil-users] Merging repositories

I think Andy's suggestion(s) are your best bet but I want to mention what I've done in the past. Is your intent to co-mingle same-named branches? I.e. if there is a trunk in both source repos do you wish to merge both dev streams to a single trunk? I have done this via brute force in the past and

Re: [fossil-users] close leaf from command-line, and 'apropos(1)'-like behaviour?

how about on creation of a fossil the help is written to the fossil as wiki pages? - then the built in search can be used. Or (yet another) option could be added to create the help or update from latest. On Tue, Jul 21, 2015 at 2:30 AM, Stephan Beal wrote: > On Tue, Jul 21, 2015 at 11:27 AM, Mic

Re: [fossil-users] quick poll: do you generally use add/rm or mv

I've been using (and advising others to use) addremove because fossil mv behavior did not match Unix mv. The differences were confusing. I've no idea if fossil mv now behaves exactly like mv. The other issue was that fossil move did not keep the filesystem in sync with fossil which is also confusin

Re: [fossil-users] quick poll: do you generally use add/rm or mv

On Wed, Aug 5, 2015 at 8:01 AM, Andy Goth wrote: > On 8/4/2015 12:59 AM, Stephan Beal wrote: > > On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig > > wrote: > >> And then, there will be fresh set of edge cases with subtly > >> different behavior on Windows. And for that

Re: [fossil-users] painful merge

On Sun, Aug 9, 2015 at 7:29 AM, Stephan Beal wrote: > On Sun, Aug 9, 2015 at 4:22 PM, arnoldemu < > mem...@arnoldemu.freeserve.co.uk> wrote: > >> kdiff3 makes it hard work, I must go and resolve every little thing >> including whitespace and empty lines. Merging multiple lines is hard work. >> So

Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)

Good support for sending email would be wonderful. We are getting along by running rss2email, far from ideal but adequate. On Sun, Aug 30, 2015, 1:55 AM Baptiste Daroussin < baptiste.darous...@gmail.com> wrote: > 2015-08-30 10:27 GMT+02:00 Stephan Beal : > > On Sun, Aug 30, 2015 at 10:15 AM, Bapt

[fossil-users] A branch that won't go away ...

We have a fossil with a branch that was closed over a year ago where the closed branch is showing up in the "fossil branch" list. I tried a few experiments, opening and closing the branch, rebuilding the repo, re-cloning etc. and that dang branch continues to show up in the command line listing BUT

Re: [fossil-users] A branch that won't go away ...

That was it. There was a very old branch that we missed. Thanks! On Oct 24, 2015 5:56 AM, "Richard Hipp" wrote: > On 10/23/15, Matt Welland wrote: > > We have a fossil with a branch that was closed over a year ago where the > > closed branch is showing up in the "

Re: [fossil-users] Question about MERGE

This is a surprisingly frequent need. Fossil is designed around a "get things right the first time" philosophy but real life is often not that crisp and clean. Being able to gracefully recover from mistakes and then get rid of the irrelevant leftover cruft would be a wonderful addition to fossil. I

[fossil-users] Why is fossil extras so slow?

time find . -name foo.bar > /dev/null ; time fossil extras > /dev/null;time find . -name foo.bar > /dev/null ; time fossil extras > /dev/null 0.064u 0.404s 0:03.80 12.1% 0+0k 0+0io 0pf+0w# find 0.204u 1.160s 0:13.03 10.4% 0+0k 0+104io 0pf+0w # fossil extras 0.032u 0.288s 0:02.25 13.7%

Re: [fossil-users] xkcd on git

Hmmm I'm in a loquacious sort of mood and this spiel got long so I'm adding a summary blurb, I recommend read the blurb and skip the rest. Summary: Modest needs of a lone developer not doing branching etc. can be met with file system based methodology. Even so IMHO an SCM is still a productiv

Re: [fossil-users] xkcd on git

On Sat, Oct 31, 2015 at 11:33 AM, Stephan Beal wrote: > On Sat, Oct 31, 2015 at 6:45 PM, Matt Welland > wrote: > > [snip] > (i) Is fossil that much less arcane? Last I checked mv, cp and rm don't >> work the same as Unix, an ongoing annoyance for my users, then ther

Re: [fossil-users] xkcd on git

On Sat, Oct 31, 2015 at 1:47 PM, Stephan Beal wrote: > On Sat, Oct 31, 2015 at 9:41 PM, Matt Welland > wrote: > >> BTW, to some extent it is ok for fossil to be opinionated software that >> strives to dictate how to do your work. However take that model very far >&g

Re: [fossil-users] xkcd on git

On Sun, Nov 1, 2015 at 2:14 AM, Stephan Beal wrote: > On Sat, Oct 31, 2015 at 10:19 PM, Matt Welland > wrote: > >> On Sat, Oct 31, 2015 at 1:47 PM, Stephan Beal >> wrote: >> >>> On Sat, Oct 31, 2015 at 9:41 PM, Matt Welland >>> wrote: >>&

Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 9:40 AM, Eric Rubin-Smith wrote: > > - Symlinks. Now we're getting into file system specifics. Some users >> may want to track them because they find them useful. What about users >> that find FIFOs or block devices or character device useful? Should >> fossil attempt to sa

Re: [fossil-users] Fossil repo on a network share?

On Mon, Nov 16, 2015 at 3:57 PM, Dömötör Gulyás wrote: > I've got an environment where it'd be good to put a fossil repo onto a > windows network share, as running an actual server is hindered by corporate > IT policy. Has anybody done this, or is this at least theoretically doable? > We have ne

Re: [fossil-users] Semi-annual drumming-up-of-support for libfossil

This is way off topic but an interesting subject. Trying this is on my to-do list: http://blog.xkcd.com/2007/08/14/mirrorboard-a-one-handed-keyboard-layout-for-the-lazy/ By using workrave (http://www.workrave.org) religiously - especially micro breaks - RSI has gone from an escalating problem to

Re: [fossil-users] Fossil and symbolic links

On Sat, Feb 6, 2016 at 4:55 PM, Yannick Duchêne wrote: > Hi people, > > I have a working directory containing symbolic links to directories. > Versioned files belong to these symbolically linked directories. > > If I have a modified file in one of these linked directory and run `fossil > gdiff` i

Re: [fossil-users] fossil update --latest not working

On Thu, Apr 7, 2016 at 5:04 AM, John Regehr wrote: > Argh, thanks, sorry for the noise! > > John > > > On 4/7/16 2:02 PM, Richard Hipp wrote: > >> On 4/7/16, John Regehr wrote: >> >>> What is the branch tag reported by fossil status? Perhaps the branch you were on got renamed? >>> >>>

[fossil-users] Request for different behavior with adding files in nested fossils

Given directory structure like this: fossildirparent - fossilsubdir where fossilsubdir is fossil nested under fossildirparent If you cd to fossildirparent and do a fossil add of a file in fossilsubdir: cd fossildirparent fossil add fossilsubdir/somefile.txt The file fossilsubdir/somefile.tx

[fossil-users] fossil help set no longer provides essential information

Older versions of fossil would provide some very helpful information from "fossil help set": gmerge-command   A graphical merge conflict resolver command operating                  on four files.               Ex: kdiff3 "%baseline" "%original" "%merge" -o "%output"               Ex: xxdiff "%orig

Re: [fossil-users] fossil help set no longer provides essential information

On Fri, 2018-01-05 at 13:42 -0500, Richard Hipp wrote: > On 1/5/18, Matt Welland wrote: > > > > Older versions of fossil would provide some very helpful > > information > > from "fossil help set": > > > > gmerge-command   A graphi

Re: [fossil-users] fossil help set no longer provides essential information

On Fri, 2018-01-05 at 13:06 -0700, Andy Bradford wrote: > Thus said Richard Hipp on Fri, 05 Jan 2018 13:42:29 -0500: > > > > > Maybe  I just  need to  improve the  "fossil help  setting" > > output  to > > provide some clue about how to get help on individual settings? > That would be an  improve

[fossil-users] Thank you developers for the unversioned feature...

I'm finding the unversioned files to be extraordinarily useful. Thanks you all for implementing it. The most recent use case I found was to solve the annoying problem of having some changes that are not quite ready to commit and needing to move to another computer. By storing a patch as an unversi

<    1   2   3   4