Re: [fossil-users] Two trunks?

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 > Server says: ** WARNING: a fork has occurred ** > Server says: ** WARNING: a fork has o

Re: [fossil-users] Two trunks?

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 should the pull issue a warning? Thanks, Andy -- TAI64 timestamp: 40005526904a __

Re: [fossil-users] Two trunks?

Thus said Ron W on Wed, 08 Apr 2015 22:27:57 -0400: > 2. The presence of such a tag will serve as a reminder that the fork > exists. If the goal is simply to make it easier to find forks, I don't think a tag is necessary for that. Fossil can already calculate the presence of forks, so may

Re: [fossil-users] Problem with ssh access

Thus said Joe Knapka on Thu, 09 Apr 2015 14:31:36 -0600: > fossil clone ssh://me@server/repo.fossil?fossil=/home/me/bin/fossil > local-repo.fossil --ssh-command=C:\cygwin\bin\ssh.exe Maybe try: fossil clone --ssh-command=C:\cygwin\bin\ssh.exe ssh://me@server/repo.fossil?fossil=/home/me/bin/fo

Re: [fossil-users] Problem with ssh access

Thus said Ron W on Thu, 09 Apr 2015 11:55:14 -0400: > Also note that the SSH command to be used can be specified by the > --ssh-command= option. (But the fossil= URL parameter is easier in > this situation.) The two options are not really related. The --ssh-command option does not defi

Re: [fossil-users] Two trunks?

Thus said Matt Welland on Wed, 08 Apr 2015 22:39:36 -0700: > > > Server says: ** WARNING: a fork has occurred ** > > > Server says: ** WARNING: a fork has occurred ** > > > > I assume you actually had 2 forks in the content that you were > > syncing? > > > > One fork: Can yo

Re: [fossil-users] Two trunks?

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 > commits has any idea that a fork was committed. Perhaps this will help: http://www.fossil

Re: [fossil-users] Problem with ssh access

Thus said Joe Knapka on Thu, 09 Apr 2015 08:51:05 -0600: > I am attempting to sync with a Fossil repo that is on a machine to > which I have no administrative access, via ssh. I have installed > fossil in ~/bin, added ~/bin to the PATH in .bash_profile, and ensured > that I can run fossi

Re: [fossil-users] Two trunks?

Thus said Ron W on Wed, 08 Apr 2015 12:13:29 -0400: > Ideally, this should never happen, but real working conditions might > dictate making a commit during non-idea situations. Right, specifically, offline checkins and situations where autosync is entirely off. I think in these cases it make

Re: [fossil-users] Two trunks?

Thus said Matt Welland on Fri, 10 Apr 2015 11:16:32 -0700: > I myself prefer not to see additional info like this that can be > derived from querying the db added to the timeline. I'm keen to see > the work that Andy and Jan have done make it into the trunk and will > test it ASAP. It'

Re: [fossil-users] Two trunks?

Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200: > - I'm not sure if I want to be reminded when someone else causes a > fork on a branch I'm not working on. But if there is such a desire > with other people, I'm not principally against it. I asked a question a few days ag

Re: [fossil-users] Two trunks?

Thus said Matt Welland on Mon, 13 Apr 2015 15:57:53 -0700: > Does fork notification really warrant another setting? Generally, I would prefer to avoid another setting, but wanted to make sure. > Forks are rare in most repos (the intensely busy repos I deal with > seem to be the exception).

Re: [fossil-users] Two trunks?

Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200: > I'll do more testing on the "sync-forkwarn". Thanks. One thing to note is that I extended the function fossil_find_nearest_fork to be able to work without checking the vmerge table which is only available for a reposit

Re: [fossil-users] Two trunks?

Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200: > 2) The additional time spent in the fork-detection is negligible. I too was concerned about the additional time that might be spent checking and whether or not it would be worth the extra time. Thanks for taking the time to profi

Re: [fossil-users] Merge question

Thus said =?UTF-8?B?Wm9sdMOhbiBLw7Njc2k=?= on Thu, 16 Apr 2015 00:16:11 +1000: > Is there a way to do that? That is, merge only a bunch of files > between two branches but leave everything else untouched on both > branches (and of course still having two branches)? Note that there

Re: [fossil-users] terminology confusion

Thus said Ron W on Thu, 16 Apr 2015 12:49:43 -0400: > Unfortunately, I had no luck finding any better term for what Fossil > calls a "fork". (My search-fu maybe off this morning.) This document contains what Fossil considers a fork: https://www.fossil-scm.org/index.html/doc/trunk/www/branching

Re: [fossil-users] Two trunks?

Thus said Jan Nijtmans on Thu, 16 Apr 2015 10:38:17 +0200: > There's a "fossil forks" command on trunk now: Thank you. Looks great. Oops... $ ./fossil new /tmp/new.fossil > /dev/null $ ./fossil forks -R /tmp/new.fossil SQLITE_ERROR: no such table: vmerge ./fossil: no such table: vmerge SELECT

Re: [fossil-users] terminology confusion

Thus said Ron W on Thu, 16 Apr 2015 15:27:38 -0400: > So I don't know of an alternative term already in use to suggest. Not > can I think of any other alternative term to suggest. I don't know of an alternative either; perhaps a duplicate descendant line. Fossil simply defines it: Having mo

Re: [fossil-users] Two trunks?

Thus said Matt Welland on Thu, 16 Apr 2015 15:55:47 -0700: > I think merging a fork resolves then it and it is no longer a fork. > Only open forks represent potentially orphaned changes. Maybe we need > better terminology. I think by definition it must be considered no longer a fork, howeve

Re: [fossil-users] Two trunks?

Thus said Ron W on Thu, 16 Apr 2015 21:04:12 -0400: > I disagree. While it might be the most common case, merging does not > explicitly state any intent beyond the merge itself, even a full > merge. After one has merged a fork, does ``fossil merge'' report that there are any more forks to

Re: [fossil-users] Merge - including files from other branches - best practice?

Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600: > It is by design. Merging isn't always intuitive, and certainly there could > be a bug in it. Perhaps like this one: http://fossil.bradfords.org:8080/info/b1e9974a37c648fe Why was that merge essentially a no-op? I'm confused... Than

Re: [fossil-users] Merge - including files from other branches - best practice?

Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600: > Partly I think it is because your test case consists of a single file > of a single line, which means probably (I would think) every merge > resulted in a conflict that you had to resolve manually. Yes, every merge is a conflict

Re: [fossil-users] terminology confusion

Thus said "j. van den hoff" on Fri, 17 Apr 2015 07:51:26 +0200: > but if changing the terminology really is a seriously considered > issue, than I cannot abstain from proposing "shoot" instead (which > would open the theoretical possibility to indicate it as `SHOOT!' in > the CLI timel

Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two trunks?)

Thus said Richard Hipp on Sat, 18 Apr 2015 07:50:42 -0400: > When the artifacts that comprise a fork are received, the server has > no way of knowing that new artifacts that resolve the fork (either by > merging or by moving it onto a branch) will not be received within the > next few milliseco

Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two trunks?)

Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200: > It seems it's not wise at this moment to merge "sync-forkwarn" to > trunk since false warnings here may be more confusing than that they > help :-( You're right. I thought I had moved it sufficiently to the end of the client_s

Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two trunks?)

Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200: > Explanation: the current code in "sync-forkwarn" doesn't do the > fork-check at the end of the sync, it does it at the end of each > round-trip. I've altered the change and now it will only check at the end of the compl

Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two trunks?)

Thus said Ron W on Thu, 23 Apr 2015 13:13:12 -0400: > Only for sync, or does it also only report new forks when "fossil > forks" is run? In my opinion, "fossil forks" should report all forks, > even previously detected ones. Yes, only in the context of a sync. E.g. someone makes a commit, y

Re: [fossil-users] Got this in WAL mode

Thus said Abilio Marques on Sat, 18 Apr 2015 21:29:36 -0430: > $ fossil ci -m "improving icon" > SQLITE_NOTICE: recovered 2 frames from WAL file C:\Documents and > Settings\Public\Documents\Unity Projects\asteroids\.asteroids.fossil-wal > ./scenes/mainScene.unity contains binary data. Use --no-war

Re: [fossil-users] Two trunks?

Thus said Ron W on Sat, 18 Apr 2015 14:19:16 -0400: > As to merging, a "branch-leaf" is not automatically closed by merging > it to anther branch, so why would merging automatically do anything to > a "fork-leaf" to make it not a fork-leaf? Because a fork is only a fork if the branching hap

Re: [fossil-users] Two trunks?

Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400: > Proposed solutions include denying the ability to commit or push a > fork. But doesn't that just make the problem worse? Yes, I think it does make it worse; this is not a practical approach in my opinion. I think it better to hav

Re: [fossil-users] Two trunks?

Thus said jungle Boogie on Fri, 24 Apr 2015 23:11:54 -0700: > Is there a /forks page on webUI? Not yet, however, I have been meaning to add one which will show only forks, similar to how the ``fossil leaves'' command was extended to show forks. Should this be a separate /forks URI or just a

Re: [fossil-users] Two trunks?

Thus said "j. van den hoff" on Sat, 25 Apr 2015 07:35:01 +0200: > I believe having these warnings would be good and would opt for making > a "field test" whether it is well accepted or not in the fossil users > community. Yes, I would like this to be in ``testing'' sufficiently long to a

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

Thus said Richard Hipp on Sat, 25 Apr 2015 16:54:51 -0400: > https://www.sqlite.org/src/timeline?c=763d2bc74b&unhide > https://www.sqlite.org/src/timeline?c=7d445e593a&unhide > https://www.sqlite.org/src/timeline?c=cbea02d938&unhide > https://www.sqlite.org/src/timeline?c=bf6ca21b36&unhide > > No

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

Thus said Matt Welland on Sat, 25 Apr 2015 19:07:11 -0700: > bf6ca looks very much like a potential accidentally orphaned commit. Actually, [bf6ca21b] also looks like a potential leaf of a fork. Sure, it was merged, but it remained an open leaf, the other side of which is [cbea02d938]: $ foss

Re: [fossil-users] Two trunks?

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 > developer may resort to the UI to determine what happened but the fix > is done at the com

Re: [fossil-users] Two trunks?

Thus said Richard Hipp on Sun, 26 Apr 2015 18:34:23 -0400: > The "forks" query parameter to the /timeline page now shows recent > forks in the check-in DAG. For this page, a "fork" means a check-in > with two or more children in the same branch. No attempt is made to > distinguish betwee

Re: [fossil-users] Two trunks?

Thus said bch on Mon, 27 Apr 2015 14:27:41 -0700: > 1) On a large repo, this takes an inordinate amount of time. On a sync > (with no updates necessary), the runtime is ~45s (on the first > attempt, I stopped it after ~10 mins of running in order to re-run it > with a time(1) command to

Re: [fossil-users] Two trunks?

Thus said bch on Mon, 27 Apr 2015 14:27:41 -0700: > 1) On a large repo, this takes an inordinate amount of time. On a sync > (with no updates necessary), the runtime is ~45s (on the first > attempt, I stopped it after ~10 mins of running in order to re-run it > with a time(1) command to

Re: [fossil-users] Two trunks?

Thus said Jan Nijtmans on Mon, 27 Apr 2015 23:41:22 +0200: > a) > I would guess this is the problem, but I could be wrong. If no content is synced, rcvid will be 0, which normally won't be a problem because the only content th

Re: [fossil-users] Two trunks?

Thus said Richard Hipp on Mon, 27 Apr 2015 19:37:09 -0400: > Is that coded needed at all? That's a fair question, and one that we've been debating over the past couple of weeks. Some feel that Fossil should warn about a fork, even those which were created ``silently'' during a sync. Thi

Re: [fossil-users] Two trunks?

Thus said Richard Hipp on Mon, 27 Apr 2015 20:28:26 -0400: > .timer on That's excellent! I was wondering if sqlite's command line tool had a profiling tool (having thought of Tcl's time as a useful profiling feature). I'll play around with this some to see what various results I get. T

Re: [fossil-users] Two trunks?

Thus said Richard Hipp on Mon, 27 Apr 2015 20:51:51 -0400: > FWIW, I created that index on Joerg's net-bsd repo and it made a Big > Improvement in performance there. That's good to know. I'm currently downloading the repository, but it's big and will be a while before I can test anything. I

Re: [fossil-users] fossil proxy web browser

Thus said Richard Boehme on Mon, 27 Apr 2015 09:07:54 -0400: > They are distinct, but I needed some way to see what my proxy's > response was, and it looks like it needs to look like a certain web > browser - it looks like the proxy rejects anything that isn't > Internext Explor

Re: [fossil-users] Two trunks?

Thus said bch on Mon, 27 Apr 2015 18:20:43 -0700: > I think enough churn has happened that this isn't necessarily > conclusive (if i'd known of the fallout, I'd have had a pre-problem > snapshot of the repo set aside so I could faithfully recreate all > steps at whim), but anywa

Re: [fossil-users] Lost in the commands and options

Thus said Abilio Marques on Thu, 07 May 2015 21:49:34 -0430: > And the report says: UPDATE test.txt (1 file modified)... Is there any > way to request that information again. Which is the easiest way? I don't know if there's a way, however, if you you do: fossil update abcd fossil undo fossil up

Re: [fossil-users] Lost in the commands and options

Thus said "Andy Bradford" on 08 May 2015 12:32:22 -0600: > fossil undo I just realized that you could probably just use: fossil undo -n And it will show you what will be undone rather than actually performing it. Andy -- TAI64 timestamp: 400

Re: [fossil-users] About the help command

Thus said paul on Fri, 08 May 2015 20:51:44 +0100: > For example, what's the difference between merge with baseline and > cherrypick? The documentation probably should explain that somewhere. When you merge, you merge in all changes leading up to that baseline (e.g. if you merge in a

Re: [fossil-users] About the help command

Thus said paul on Fri, 08 May 2015 21:17:36 +0100: > OK, so if I do a merge with baseline, supply two UUID's so that I only > merge the changes for one UUID, are you saying that cherrypick is a > shortcut for that, because you only need to supply one UUID with > cherrypick? I see, you'

Re: [fossil-users] Change Branche color

Thus said Kai Lauterbach on Sat, 09 May 2015 16:22:47 +0200: > But it does not work for me, it dies not change the color in the > Webinterface. But change of the color for one commit is possible. If you already have a branch, then the only way to change the color of the entire branch is

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

Thus said Abilio Marques on Mon, 11 May 2015 09:27:53 -0430: > I wondered back then, what would it take to implement this for fossil. > The first thing that popped to my head was the protocol. I gave a > quick glance back then, and I recall seeing no way of detecting a > "push" to a spe

Re: [fossil-users] Automatic editor detection.

Thus said John Found on Tue, 12 May 2015 23:33:00 +0300: > BTW, I found shorter form, without defining variable: I usually just use: EDITOR=vi; export EDITOR :-) Andy -- TAI64 timestamp: 400055526e2a ___ fossil-users mailing list fossil-users@lis

Re: [fossil-users] Is this a fork?

Thus said jungle Boogie on Sun, 17 May 2015 17:16:42 -0700: > More fork examples exist in the timeline: > http://www.fossil-scm.org/index.html/timeline.rss Technically speaking, the examples you've given *are* forks. While they are not examples of an unnamed fork that was recently under discuss

Re: [fossil-users] andygoth-user-reports

Thus said jungle Boogie on Sun, 17 May 2015 21:22:21 -0700: > To me, this list says Mr. Bradford did some kind of check-in with > these files listed here. A checkin does not necessarily mean that one made changes to a specific file; it means that a specific file was part of a checkin. For

Re: [fossil-users] andygoth-user-reports

Thus said jungle Boogie on Mon, 18 May 2015 10:45:54 -0700: > Got it, cool. Thanks for the clarification! Perhaps... Andy Goth actually thinks the behavior is a bug and provided a link to some steps to cause the behavior. I'm not sure without further investigation. Andy -- TAI64 timestamp: 400

Re: [fossil-users] workflow question

Thus said "j. van den hoff" on Wed, 27 May 2015 12:10:57 +0200: > the "request to work on branch" is the catch: he wants to ensure that > students can never mess up trunk, i.e. must technically not be able to > merge anything into trunk. Trunk in *which* clone of the repository? Perhaps the

Re: [fossil-users] how to move commits to a different branch

Thus said paul on Thu, 28 May 2015 16:57:57 +0100: > I'm don't think it's possible to use the command line for this. It is possible. I've done it. It just takes a strong understanding of how propagating tags works and requires multiple commands with just the right types of tags. There is no

Re: [fossil-users] how to move commits to a different branch

Thus said Ron W on Thu, 28 May 2015 11:43:07 -0400: > fossil tag cancel --raw 'branch' 53c9207df8 ramo > fossil tag cancel --raw sym-trunk 53c9207df8 > fossil tag add --raw --propagate 'branch' 53c9207df8 ramo > fossil tag add --raw --propagate 'sym-ramo' 53c9207df8 Yes, th

Re: [fossil-users] how to move commits to a different branch

Thus said Richard Hipp on Thu, 28 May 2015 12:31:06 -0400: > Not strictly true, but true enough in practice. Perhaps it would be > worthwhile to add a new command-line way of moving a check-in to a new > branch. Suggested syntax, anyone? ``fossil branch new'' almost does what we want but it ac

Re: [fossil-users] how to move commits to a different branch

Thus said Richard Hipp on Thu, 28 May 2015 12:31:06 -0400: > Not strictly true, but true enough in practice. Perhaps it would be > worthwhile to add a new command-line way of moving a check-in to a new > branch. Suggested syntax, anyone? What if instead of a new addition to ``fossil branch''

Re: [fossil-users] how to move commits to a different branch

Thus said Luca Ferrari on Fri, 29 May 2015 13:59:17 +0200: > But if I could say, the option "newbranch" does not look good at me, > since it a little too long. Fossil can have both long and short names for a given option, but perhaps --newbranch is too long. What about just --branch? An

Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:

Thus said to...@acm.org on Fri, 29 May 2015 20:57:16 +0300: > Is my repo corrupt or what's wrong with the new (or the old) version? Did you remember to make clean before building and optionally rerun ./configure? Thanks, Andy -- TAI64 timestamp: 40005568acbb ___

Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:

Thus said to...@acm.org on Fri, 29 May 2015 20:57:16 +0300: > (1) 2015-05-29 17:48:57 [eba9fa6147] (current) > (2) 2014-11-05 13:36:22 [91ef16c613] What artifacts are these? Fossil doesn't have them: https://www.fossil-scm.org/index.html/info/eba9fa6147 https://www.fossil-scm.org/index.html

Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:

Thus said to...@acm.org on Fri, 29 May 2015 22:18:00 +0300: > Check-in d137 was originally trunk but moved to a branch ``mistake.'' > (I guess shunning would have been a better solution at the time, but > too late now, right?) Actually, shunning was probably never a better solution for this ki

Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:

Thus said to...@acm.org on Sat, 30 May 2015 01:29:10 +0300: > And, using --force does nothing, of course. Actually, it does. Did you try to run ``fossil ci'' after running ``fossil merge --force'' to actually commit your changes? There will be no files changed as part of the merge,

Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:

Thus said to...@acm.org on Sat, 30 May 2015 01:29:10 +0300: > As to what happened you probably guessed right. I must have used the > --branch option from within the 'mistake' branch. I was (until just > now) under the impression that the --branch option either starts a new > branch (if the na

Re: [fossil-users] Standalone server slowing down significantly after long use

Thus said Philip Bennefall on Tue, 02 Jun 2015 20:12:15 +0200: > This is a hard case to reproduce as it usually takes several weeks or > even a month or two, but after the Fossil standalone server has been > running for quite some time it becomes terribly sluggish. Has the process been reniced

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

Thus said "Ardie H. Hwang" on Thu, 04 Jun 2015 06:01:15 +0900: > Clearly, server does not know the existence of check-in > `da19b8f2e5d89310d80b90a6a27d2d70ff646ad1`. > Is there any advice on resolving this issue? Have you tried: fossil push Thanks, Andy -- TAI64 timestamp: 4000556fa631 _

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

Thus said "Ardie H. Hwang" on Thu, 04 Jun 2015 13:57:12 +0900: > I did not issue `fossil push` because I wasn't sure whether the local > repo is in stable state or not, although the error occurred at sync > phase. Based on the output you provided, Fossil hit an assertion during opening a conn

Re: [fossil-users] DB corruption and error msg string mis-handling.

Thus said bch on Mon, 08 Jun 2015 15:31:31 -0700: > rid: size > == What are some of the SHA1 hashes for these RIDs? Thanks, Andy -- TAI64 timestamp: 40005579f382 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.f

Re: [fossil-users] Issue with cloning a repo

Thus said =?UTF-8?Q?Jacek_Ca=C5=82a?= on Tue, 16 Jun 2015 16:44:42 +0100: > $ fossil clone http://USERNAME@SERVERNAME/REPONAME repo.fossil > > it fails reporting: > > getaddrinfo() fails: Name or service not known Mind sharing the actual hostname for SERVERNAME? It's possible there's some kin

Re: [fossil-users] SQLITE_BUSY ?

Thus said Joerg Sonnenberger on Wed, 17 Jun 2015 11:38:46 +0200: > It's possible to hit one of the hidden master -> public repo pushes, > they can take a bit as the disks are generally busy in the machine > with other conversions :) If I'm not mistaken, some changes were made to help with l

Re: [fossil-users] DB corruption and error msg string mis-handling.

Thus said bch on Tue, 23 Jun 2015 11:58:35 -0700: > Good idea (I presume you mean sqltrace): More likely he meant --httptrace which will reveal the HTTP transactions during the pull operation (e.g. what was sent/received). Andy -- TAI64 timestamp: 40005589adfe ___

Re: [fossil-users] Fwd: DB corruption and error msg string mis-handling.

Thus said bch on Tue, 23 Jun 2015 13:40:04 -0700: > See attached. I don't see any examples of receiving empty artifacts. Andy -- TAI64 timestamp: 4000558a034e ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-sc

Re: [fossil-users] how to move commits to a different branch

Thus said jungle Boogie on Mon, 22 Jun 2015 23:04:06 -0700: > Do you think you'll be implementing the new commands? Yes, it took a bit longer to get into it than I expected, but an intial implementation has finally been committed: http://www.fossil-scm.org/index.html/info/b9e0d72e7e6da002 It c

Re: [fossil-users] how to move commits to a different branch

Thus said Stephan Beal on Sat, 04 Jul 2015 09:56:42 +0200: > The name 'edit' seems kinda... appropriate but potentially confusing, > as it initially (to me) sounds like it's going to start $EDITOR. Yeah, I had similar reserves about using that name, but nothing better came to mind. I thought a

Re: [fossil-users] how to move commits to a different branch

Thus said Stephan Beal on Sat, 04 Jul 2015 18:22:35 +0200: > The more i think about it, the more i like the name 'amend'. Yes, I'm starting to agree, amend may be the winner. Anyone else have an opinion. Thanks, Andy -- TAI64 timestamp: 400055981204 __

Re: [fossil-users] multiple open leaf checkins on trunk

Thus said Stephan Beal on Mon, 06 Jul 2015 08:37:16 +0200: > [stephan@host:~/cvs/fossil/cwal]$ f up > ... > comment: back-ported in fix from cson: render characters>0x in > JSON as UTF16 surrogate pairs. (user: stephan) > changes: None. Already up-to-date > WARNING: multiple open lea

Re: [fossil-users] multiple open leaf checkins on trunk

Thus said Stephan Beal on Mon, 06 Jul 2015 08:37:16 +0200: > i don't understand what the above warning is trying to tell me. 1e657 > appears (based on the timeline) to be completely in order, not forked. It may be a manifestation of the ``fossil pull'' bug mentioned here: http://www.mail-archiv

Re: [fossil-users] multiple open leaf checkins on trunk

Thus said Stephan Beal on Tue, 07 Jul 2015 04:56:13 +0200: > Turns out i had to run a rebuild on the _local_ copy of the repo, not > the remote. Doing so fixes this behaviour. Oops, sorry I wasn't more clear. Yes, the problem is local. Andy -- TAI64 timestamp: 4000559b4293 __

Re: [fossil-users] Possible bug with [G]DIFF

Thus said "Tony Papadimitriou" on Tue, 07 Jul 2015 16:54:30 +0300: > f gdiff --from 2015-07-07 > > where the 2015-07-07 date is today, or any date later than the latest > check-in, I get a list that looks like the execution of a CHANGES > command, which is is certainly incorrect. What versi

[fossil-users] Strange timeline bug with dp parameter.

Hello, I was perusing the Fossil timeline from here: http://www.fossil-scm.org/index.html/timeline?n=50&y=all&v=0&c=2015-07-11 I then clicked on the link from edit [2821e284] and it took me here: http://www.fossil-scm.org/index.html/timeline?r=enhancedUndo-test&nd&dp=2821e284c5337529&unhide Wh

Re: [fossil-users] Strange timeline bug with dp parameter.

Thus said Andy Goth on Mon, 13 Jul 2015 14:34:11 -0500: > I found the same bug and reported to the list. There were no replies. > > https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20593.html Yep, that's it. In fact, as I sent the email I remember having a nagging feeling of h

Re: [fossil-users] Standalone server slowing down significantly after long use

Thus said Philip Bennefall on Wed, 15 Jul 2015 20:22:07 +0200: > About a month ago I reported having some issues with the standalone > Fossil server, where it would slow down significantly after running > for an extended period. What specifically is slow? Clone? Sync? Accessing pages serv

[fossil-users] Any interest in testing/merging check-in-edit branch?

Hello, Has anyone (other than me) tested the changes for enabling amending checkins from the command line in the check-in-edit branch? I think it's ready, but it certainly could use additional testing given that it also includes changes that affect the web ci_edit page (primarily

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Michai Ramakers on Thu, 16 Jul 2015 14:56:49 +0200: > I don't know what the intended behaviour was w.r.t. bogus input on > commandline - e.g. 'fossil amend tip something_bogus' does nothing > (and prints nothing). Definitely would expect an error here, specifically not recogniz

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Thu, 16 Jul 2015 08:19:00 +0200: > for bonus points (certainly not necessary), allow multiple > f-tag/-cancel lags: Yes, I considered that but wasn't certain if others would be interested. The ci_edit page only allows one I believe so I mirrored that behavio

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Sergei Gavrikov on Thu, 16 Jul 2015 17:21:55 +0300: > I also expected that 'fossil amend ' will spawn $EDITOR with an > original check-in message likes 'fossil commit' does. That's actually a good idea. The problem with --comment as currently implemented is that it allows you to re

Re: [fossil-users] Merging repositories

Thus said =?UTF-8?B?Wm9sdMOhbiBLw7Njc2k=?= on Fri, 17 Jul 2015 09:27:48 +1000: > My question is, is it possible to move artefacts from one Fossil > database to an other? This is all hypothetical... It's certainly not in the realm of impossibility. But Fossil wasn't really designed to

Re: [fossil-users] Merging repositories

Thus said Andy Bradford on Thu, 16 Jul 2015 20:56:57 -0600: > Maybe rather than doing a pull, you could deconstruct both > repositories, put the extracted artifacts into the same place, > fabricate a manifest that somehow merges the two timelines with files > fro

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Fri, 17 Jul 2015 06:55:29 +0200: > Or maybe it's just me! I disagree, I don't think it's you at all. Filtering problems are always due to faulty design or bad heuristics. If I filter email (or gmail in this case) that happens to be legitimate email, regardless of

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Sergei Gavrikov on Thu, 16 Jul 2015 17:21:55 +0300: > I also expected that 'fossil amend ' will spawn $EDITOR with an > original check-in message likes 'fossil commit' does. But, I met cold > silence. Probably, to support $EDITOR for 'amend-commit' isn't trivial > and I cannot insist o

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Sat, 18 Jul 2015 09:46:40 +0200: > Why is 'e'user needed? Is there a global flag for --user which > collides with it? Yes, unfortunately there is the global --user option with which it collides. Setting it causes Fossil to fail with an error about not being

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Scott Robison on Fri, 17 Jul 2015 22:20:35 -0600: > On phone, apologies for top posting. To me "amend " should > behave as much as possible like "commit", though I can appreciate that > some might disagree. Is the primary purpose, or most frequent use, of the amend subcommand to e

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Sergei Gavrikov on Sat, 18 Jul 2015 15:18:09 +0300: > Back to amend's options. Short counter-part for `--comment' option > would be `-m' option. The fossil commit command uses `-m'. Yes, much better suggestion, thank you. I'll take a look at the commit command and see how many

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Sat, 18 Jul 2015 16:35:46 +0200: > -e|--edit-comment Launch editor to revise comment > > i know my own most-used will be -e, but i like -m (as mentioned > earlier) for this: -m|-comment for symmetry with commit. #2 would be > tagging, #3 would be the t

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Sergei Gavrikov on Sat, 18 Jul 2015 12:10:42 +0300: > However, with a forest the options Fossil CLI increasingly resembles > Git CLI :-) Perhaps then, ``amend'' should only have short options where ``commit'' has short options? I think this should be the case just so people who us

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Thu, 16 Jul 2015 08:19:00 +0200: > for bonus points (certainly not necessary), allow multiple > f-tag/-cancel lags: An unlimited of them (except of course by memory)? Or Fossil only account for a maximum number of tags? If the latter, what? Thanks, A

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Tue, 21 Jul 2015 09:28:43 +0200: > > > for bonus points (certainly not necessary), allow multiple > > > f-tag/-cancel lags: > > > > An unlimited of them (except of course by memory)? Or Fossil only > > account for a maximum number of tags? If the latter, what?

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

Thus said Michai Ramakers on Tue, 21 Jul 2015 11:06:31 +0200: > Is there a way using legacy commands? You can always use fossil tag, however, using it requires more knowledge of internal mechanisms than you probably care to know. Andy -- TAI64 timestamp: 400055aec1d1

Re: [fossil-users] Any interest in testing/merging check-in-edit branch?

Thus said Stephan Beal on Tue, 21 Jul 2015 09:28:43 +0200: > To be honest, i wouldn't bother with this - the code overhead of > having to collect and sort the tags would not be worth it for this > case, IMO. In principle there is no inherent limit. Save it for v2 ;). Also, I just reali

<    4   5   6   7   8   9   10   11   >