[fossil-users] Different file count after FOSSIL REBUILD --COMPRESS

[Tony Papadimitriou]

(Apologies if this message appears twice – I’m having some SMTP issues.)

I attempted to minimize storage by running “fossil reb --compress” on various 
fossils.  Only one result was unexpected.
Below is a copy of the db --db-check before and after a REBUILD with –-COMPRESS 
option.  The ‘after’ is counting one file less.

1. What could be the reason for that (4299 files instead of 4300)?
2. Is there some way to find out which file is missing by comparing to a backup?
3. Is it safe to assume (based on the db –db-check command) that the repo is 
not corrupt in any way?

Thank you.

--

c:\pp\progs>f db -db-check
project-name:  pascal
repository-size:   23283200 bytes (23.3MB)
artifact-count:7618 (stored as 3187 full text and 4431 delta blobs)
artifact-sizes:57645 average, 1479020 max, 439082200 bytes (439.1MB) total
compression-ratio: 18:1
check-ins: 1016
files: 4300 across all branches
wiki-pages:5 (9 changes)
tickets:   16 (26 changes)
events:2
tag-changes:   24
latest-change: 2019-03-23 07:56:37 - about 15 days ago
project-age:   1894 days or approximately 5.19 years.
project-id:006b33ce7cb4bad7c65266e30a729257676ec318
schema-version:2015-01-24
fossil-version:2018-01-22 23:35:07 [8360bd000d] [1.37] (msc-18.00)
sqlite-version:2018-01-22 18:45:57 [0c55d17973] (3.22.0)
database-stats:45475 pages, 512 bytes/pg, 0 free pages, UTF-8, delete mode
database-check:ok

c:\pp\progs>f reb --compress
  100.0% complete...
Extra delta compression... done
Vacuuming the database... done

c:\pp\progs>f db -db-check
project-name:  pascal
repository-size:   22311424 bytes (22.3MB)
artifact-count:7618 (stored as 3158 full text and 4460 delta blobs)
artifact-sizes:57645 average, 1479020 max, 439082200 bytes (439.1MB) total
compression-ratio: 19:1
check-ins: 1016
files: 4299 across all branches
wiki-pages:5 (9 changes)
tickets:   16 (26 changes)
events:2
tag-changes:   24
latest-change: 2019-03-23 07:56:37 - about 15 days ago
project-age:   1894 days or approximately 5.19 years.
project-id:006b33ce7cb4bad7c65266e30a729257676ec318
schema-version:2015-01-24
fossil-version:2018-01-22 23:35:07 [8360bd000d] [1.37] (msc-18.00)
sqlite-version:2018-01-22 18:45:57 [0c55d17973] (3.22.0)
database-stats:43577 pages, 512 bytes/pg, 0 free pages, UTF-8, delete mode
database-check:ok___
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] Perception of Fossil

[Tony Papadimitriou]

-Original Message- 
From: Richard Hipp



Other ideas for what to name this (hypothetical and unimplemented) command:

  fossil contribute
  fossil bequest
  fossil bestow
  fossil proffer


Some more ideas (in random order):

fossil chip-in  (shortest possible is ch)
fossil enqueue (shortest: en) and it could be matched by a fossil queue 
(shortest: q) command to quickly check the pending queue

fossil inbound (shortest: inb)
fossil try-request (shortest: tr)
fossil consider (shortest: cons)
fossil evaluate (shortest: ev)

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Moving Wiki/MD files between Wiki list on web UI and source tree, and previewing

[Tony Papadimitriou]

1. I have some Wiki/MD files created from the web UI.  Can I move them to the 
source tree and still keep access to them from the web UI?

And the reverse.

2. I have some Wiki/MD files in the source tree (which I can see with the 
http://repo/doc/version/filename.[md/wiki] link) but I cannot figure out how to 
associate that link as a Wiki page shown in the Wiki list of the Web interface.

Can someone point me to some related documentation, or (if the process is not 
too verbose) explain here?

3. Is there a more ‘immediate’ command-line method to review my source-tree 
Wiki/MD file(s) before committing my changes?
I mean some way to see how the Wiki/MD will actually show.  Can I do ‘fossil 
ui’ followed by some option to do this?

I now do it with copy/pasting to the Wiki SandBox but it seems a bit too many 
steps for when dealing with source tree files (copy everything to clipboard, 
switch to web UI window, copy to the SandBox edit box, and press preview).

This makes the web UI Wiki/MD editor with its preview option much simpler, but 
not if you want to keep the Wiki/MD also in your source tree.

Thank you.___
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] Windows GUI that allows diff between tworevisions?

[Tony Papadimitriou]

I use WinMerge (http://winmerge.org/) which also let's you edit if you like. 
Set as default with something like: fossil set gdiff-command 
c:\WinMerge\WinMergeU.exe
There is also WinDiff (by MS) that doesn't let you edit, but it is an older 
app and I'm not sure where I found it.


-Original Message- 
From: Gilles

Sent: Tuesday, February 13, 2018 12:44 AM
To: fossil-users@lists.fossil-scm.org
Subject: Spam?(14.031):[fossil-users] Windows GUI that allows diff between 
tworevisions?


Hello,

Fuel* doesn't support diffing two revisions of a file in the repository:

https://s14.postimg.org/h528wio5t/Fossil.Fuel.diff.two.revisions.png

Since it hasn't been updated since 2015… is there another Windows GUI
application that supports this?

Thank you.

* https://fuel-scm.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] -db-check compression ratio

[Tony Papadimitriou]

-Original Message- 
From: Warren Young


* The second is the presence of free pages not yet vacuumed.  This is 
unused space that IMO ‘unfairly’ lowers the ratio.


I disagree.  The unused free pages *should* be charged against you, because 
that is space Fossil is taking on your disk, and thus should be compared to 
the size of all the versions checked out.


Well, differences of opinion!
Free pages are generated 'behind the scenes', usually without the user's 
direct control or consent.
Hypothetically, Fossil could decide to unnecessarily use half my disk for 
its own convenience.  I *should not* be charged for it because I did not 
choose this behavior.

What I should be charged for is my own content in the repo.
Besides, one has to keep vacuuming on very regular basis just to get 
accurate reporting.   A bit inconvenient, no?


the compression ratio is not meaningful in a useful way when the repo 
includes either big un-versioned files


If you have a .zip file at, let us say, 2.1:1 compression ratio because it 
mostly contains text files, then you add an MP3 to it, the compression 
ratio will drop.  Is that also incorrect?


Ah, but a repo is not a zip file, semantically.  A zip file keeps files on 
'equal' terms, so to speak, and therefore they should all be accounted for 
just the same.

It's not a question of file type, file extension, or file size.

A repo on the other hand has the (primary) job of keeping versioned history.
Un-versioned files are there for convenience and they normally do not affect 
the progress of the versioned project.
A project should be functional even if we remove the un-versioned files. 
So, not same-class citizens, in my book.


Obviously, in the end, it's all a matter of perspective.  To me, at least, 
compression ratio should relate only to versioned history to be a useful 
metric.


Thank you. 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] -db-check compression ratio

[Tony Papadimitriou]

It appears that the compression ratio shown with the ‘fossil db –db-check’ 
command is based on the actual total file size of the repo against the would-be 
size of all expanded versions stored separately (based on description here: 
https://www.fossil-scm.org/xfer/doc/trunk/www/stats.wiki).

There are two cases, however, that IMO the command gives a false impression of 
the actual compression achieved in the repo.

* The first is the inclusion of un-versioned files which although inflate the 
total file size have no play in the versioning part, which is what I believe 
the compression ratio was meant to highlight.

* The second is the presence of free pages not yet vacuumed.  This is unused 
space that IMO ‘unfairly’ lowers the ratio.

Taken from the wiki page earlier “... hence the SQLite project gets excellent 
73:1 compression”

If we were to add several big un-versioned files (such as an assortment of 
pre-built binaries for various configurations and platforms) the repo size will 
obviously increase dropping ‘unfairly’ (IMO) the ‘excellent’ ratio of 
compression, when in fact it hasn’t changed at all with respect to the 
versioned history.

So, in practice, the compression ratio is not meaningful in a useful way when 
the repo includes either big un-versioned files or too many free pages, and 
could be improved to ignore those two cases from the computation.

Your thoughts?
___
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] More timeline changes

[Tony Papadimitriou]

The idea looks very good to me.  But the ellipses are indeed barely visible.
How about replacing ... with [*] as a generic (foot)note mark?

-Original Message- 
From: Richard Hipp 


Timelines now come up in Basic mode, which means only the check-in
comment shows.  There are ellipses at the end of each comment.  If you
click on the ellipsis for one comment, it expands the (detail) section
for that one timeline entry.

The ellipses at the ends of comments in basic mode are barely visible.

D. Richard Hipp

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL crash when searching WIKI from GUI

[Tony Papadimitriou]

Seems OK now.

-Original Message- 
From: Richard Hipp 


Please rebuild using the latest trunk check-in and let me know if you
encounter any more problems.

--
D. Richard Hipp
d...@sqlite.org

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL crash when searching WIKI from GUI

[Tony Papadimitriou]

I forgot to mention this is a on Windows machine (in case it matters.)

It happens with whatever repo I try (including the current sqlite3 and 
fossil).

But, you need to type the dot at the search box, not with the URL.

So, go Admin/Search and enable Search Wiki (apply changes), then go to the 
Wiki tab and enter a dot in the search box and press the button.


It also happens with Ticket Search (and I didn't try the others) so I 
suppose it's a common issue for all searches done this way.


-Original Message- 
From: Richard Hipp


On 11/17/17, Tony Papadimitriou <to...@acm.org> wrote:

Just to report an issue I noticed today.

If I put just a dot [.] in the GUI Wiki/Search box and press ‘Search Wiki’
it crashes.

This happens both with v1.37 that I normally use, and with version 2.4
[a0001dcf57] 2017-11-03 09:29:29 UTC



Seems to work ok for me.  https://www.fossil-scm.org/fossil/wiki?s=.

Can you point me to a specific example that fails?

--
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

[fossil-users] FOSSIL crash when searching WIKI from GUI

[Tony Papadimitriou]

Just to report an issue I noticed today.

If I put just a dot [.] in the GUI Wiki/Search box and press ‘Search Wiki’ it 
crashes.

This happens both with v1.37 that I normally use, and with version 2.4 
[a0001dcf57] 2017-11-03 09:29:29 UTC

Thank you.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Questions about UNVERSIONED

[Tony Papadimitriou]

A couple of questions about how unversioned files relate (or not) to normal 
repo files.

1. When adding and then removing an unversioned file, does the file get 
completely removed, or just the reference to it from the unversioned file list 
is removed but the actual ‘blob’ remains?  (If not automatically removed, how 
do I do so? REBUILD?)

2. If an unversioned file happens to also be part of the repo’s committed 
history at any point in time, do I now have two copies or one in the fossil 
file?  And will removing the unversioned one affect the committed one since 
they share the same SHA?

Thank you.___
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] Is there a way to specify paths relative to checkout's root?

[Tony Papadimitriou]

OK, thanks.

But, what would be wrong with using / which is closer semantically, and 
compatible to both Linux and Windows path syntax?

From: Stephan Beal 
Sent: Thursday, September 07, 2017 7:46 PM
To: fossil-users 
Subject: Re: [fossil-users] Is there a way to specify paths relative to 
checkout's root?

There's not currently, and if someone wants to implement it i would suggest : 
as a prefix, since fossil does not allow : in file names (for Windows 
compatibility).


- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and 
top-posting.

On Sep 7, 2017 18:43, "Tony Papadimitriou" <to...@acm.org> wrote:

  For example, assuming a checkout tree like this:

  lib/file
  a/b/c/d/e/f/g/h/j/file

  and while inside the j subdirectory, I want to refer to lib/file by doing 
something like:

  fossil tim –p /lib/file

  instead of 

  fossil tim –p ../../../../../../../../lib/file

  (and not sure if I got the number of ../ right, see the problem?)

  Similar to how one uses ~ to refer to home path in Linux, although I’m 
interested for this to work in Windows also.

  I tried both ~ and / with no success.
  (I guess / would be the obvious way to do this as it’s the checkout’s logical 
root.)

  Is there a way to do this?

  Thanks.

  ___
  fossil-users mailing list
  fossil-users@lists.fossil-scm.org
  http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is there a way to specify paths relative to checkout's root?

[Tony Papadimitriou]

For example, assuming a checkout tree like this:

lib/file
a/b/c/d/e/f/g/h/j/file

and while inside the j subdirectory, I want to refer to lib/file by doing 
something like:

fossil tim –p /lib/file

instead of 

fossil tim –p ../../../../../../../../lib/file

(and not sure if I got the number of ../ right, see the problem?)

Similar to how one uses ~ to refer to home path in Linux, although I’m 
interested for this to work in Windows also.

I tried both ~ and / with no success.
(I guess / would be the obvious way to do this as it’s the checkout’s logical 
root.)

Is there a way to do this?

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is there a way to see history (e.g., annotate) for a single line of code?

[Tony Papadimitriou]

When doing ‘annotate’ on a certain file version I see the most recent commit 
responsible for each line in the file.  That’s great!

However, if I want to know which previous commits (history) touched one 
specific line, is there some way to do this?

Thanks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Could FOSSIL UNV EX destination filename be optional?

[Tony Papadimitriou]

In the UNVERSIONED export subcommand:
export FILE OUTPUT   Write the content of FILE into OUTPUT on disk

would it be easy to make the OUTPUT filename optional so that if not present 
the same name as FILE is assumed?

Thanks.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion: WIKI command EXPORT clean of tags

[Tony Papadimitriou]

I use Wiki a lot for keeping short notes/memos about pretty much anything 
related to the host repo.
For cosmetic purposes when viewing from a Web browser these notes often contain 
 ...  or other such formatting tags.

However, doing most programming from the command-line, when I want to quickly 
look up some notes, I often do (f=fossil):

f wik exp PAGENAME

to get the related note displayed on the console screen.

However, these formatting tags are displayed cluttering the display (for some 
heavily formatted pages to the point of being unreadable).

My suggestion is when ‘wiki export’ command is used without the optional file 
(which would save wiki page to a file, as is), and the console is the target to 
filter out all those formatting tags.  A simple example:

The way it is now I would get: f wik exp "pinout"

BDM pinout

  *  PIN 1 - BKGD
  *  PIN 2 - GND
  *  PIN 3 - NC
  *  PIN 4 - RESET
  *  PIN 5 - NC
  *  PIN 6 - VCC

With the filter, a cleaner view:

BDM pinout

  *  PIN 1 - BKGD
  *  PIN 2 - GND
  *  PIN 3 - NC
  *  PIN 4 - RESET
  *  PIN 5 - NC
  *  PIN 6 – VCC

I currently use a Lua script to do this cleaning by piping the output through 
it, so I have to use something like:

f wik exp "pinout"  | cleanhtml

but it would be nice if FOSSIL could do this filtering on its own given you do 
not normally want to see those tags when displaying the wiki page on the 
console.  However, if there are tags inside a  ...  they 
should remain visible.

What do you think?

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Where can I find a pre-compiled 32-bit Linux version?

[Tony Papadimitriou]

I need a pre-compiled 32-bit Linux version of the release fossil
(The same Windows version says: This is fossil version 2.2 [81d7d3f43e] 
2017-04-11 20:54:55 UTC)

The download page only offers a 64-bit Linux version.

(I’m locked out from being able to update either fossil or sqlite3 directly 
from Linux.)

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] Minor bug with SEARCH command

[Tony Papadimitriou]

An alternate fix for [2d69772e] so that SEARCH without target behaves the same 
both from within an open repo, and with the –R option.

if( g.argc<2 ) return;
blob_init(, g.argc<3?"":g.argv[2], -1);
___
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] Problem with: fossil revert -r xxx

[Tony Papadimitriou]

Hmm, I happen to use the REVERT command *all* the time.  It's the simplest 
(and possibly only direct) way I know to quickly abort all changes (after 
experimenting with code) and go back to what was the check-in.  How do the 
rest of you do an abort?


I must admit I very rarely used the -r option, though.  But I have certainly 
needed a quicker way to backout multiple check-ins in one go (if this was 
supported), rather than one at a time.


-Original Message- 
From: Richard Hipp

Sent: Thursday, May 11, 2017 2:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Problem with: fossil revert -r xxx

On 5/11/17, Ross Berteig  wrote:

On 5/10/2017 8:54 PM, Ron Aaron wrote:


I tried to revert to a good revision 'xxx' using "fossil revert -r xxx"


But in my experience, fossil revert is a rarely used command.



Yeah.  In fact, I didn't even remember that there was a 'revert'
command.  And even now, I'm not entirely clear what it does, or what
it is intended to do.

The original "revert" command was added on 2007-09-24 (very early in
Fossil's history) by user "jnc" - I'm not sure who that is.

I have just now checked in a change to moves the "revert" command off
of the "fossil help" menu, so that you now only see it when you do
"fossil help --all".

--
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] Limiting cruft in my repos

[Tony Papadimitriou]

So, ignore ‘makefile’?

From: Ross Berteig 
# ignore files without at least one dot somewhere in their name
!*.*
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Minor bug with SEARCH command

[Tony Papadimitriou]

(Tested under Win7)

With FOSSIL SEA from within an open repository up to 1000 lines are printed by 
default. Seems OK.

Now, if the same command is given with the –R option to the same repo (e.g., 
FOSSIL SEA –R repo.fossil) the results are different, and somewhat random.

If an empty string is explicitly provided, the results again seem OK (e.g., 
FOSSIL SEA –R repo.fossil “”)

(It seems like the search target is left uninitialized to empty string in the 
–R case.)

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] Is there a way to find identical files?

[Tony Papadimitriou]

Thank you.  I regret I didn't explain well enough what I was after.

I'm looking for the simplest way (possibly even SQL, if nothing else is 
available) that I can get a list of all files in my repo that have 
duplicates, triplicates, or more in other folders (the comparison should be 
in terms of artifact ID -- as there can also be duplicates that may have 
different artifact IDs but are essentially the same content -- e.g., 
different line endings or indentation), grouped together by artifact ID 
(even if the ID itself is not displayed -- I care for the just the paths, 
not the IDs per se).


(Having to specify IDs one by one on the GUI interface for each and every 
file in the repo is not the way to go.)


For example, if
/defs.inc is the same as /project1/defines.inc,
and project2/lib.mod is the same as project3/library.inc and 
project4/libroutines.inc,

and docs/mydocs.pdf is the same as project1/docs.pdf,
I would like some simple report like this:

defs.inc
project1/defines.inc

project2/lib.mod
project3/library.inc
project4/libroutines.inc

docs/mydocs.pdf
project1/docs.pdf

(a blank line --or whatever other separator -- simply separates each group)

Ideally from the command line so that I can redirect to a file.

Thank you.

-Original Message- 
From: Richard Hipp

Sent: Monday, April 17, 2017 12:57 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Is there a way to find identical files?

On 4/17/17, Tony Papadimitriou <to...@acm.org> wrote:

Is there a way to find identical files by the artifact ID?



The empty file has a (SHA1) hash of
da39a3ee5e6b4b0d3255bfef95601890afd80709.  So if you visit the page
that shows this artifact, it lists all of the files that are empty:

   https://www.fossil-scm.org/fossil/artifact/da39a3ee5e6b4b0d
--
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

[fossil-users] Is there a way to find identical files?

[Tony Papadimitriou]

Is there a way to find identical files by the artifact ID?

So, if ID 123456... appears two or more times in the repo, I want to see all 
the related paths.

(This could be either for a single check-in or the whole repo regardless of 
check-in.)

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Shouldn't .DUMP preserve the page size?

[Tony Papadimitriou]

Although not a critical issue, I think a dump should preserve the original 
database’s page size (pragma page_size).
Some databases have been squeezed significantly by using some non-default value.
I feel this optimization should not be lost when restoring from a dump.

(I suppose there may be other pragma settings related that could/should be 
preserved by a .dump but I’m not sure at this point.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Crash with this AMEND command

[Tony Papadimitriou]

The following command crashes fossil (older and up to current version).

fossil am trunk -R your_repo_here.fossil –e

(I thought the –R option was supported for this command, but regardless it 
shouldn’t crash.)
___
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] Progress report of Fossil 2.x

[Tony Papadimitriou]

-Original Message- 
From: Warren Young



(3) New repositories are initialized using SHA3
Maybe there should be a “fossil init --sha1” option for the technologically 
conservative.


Or, for practical reasons.  So, I second that.

For example, creating a new repo locally to be hosted by chiselapp (which is 
still running 1.34 BTW) would fail.
Of course, there is the option of creating on chiselapp and then cloning and 
continuing from there, but it should be able to work both ways because one 
may discover the problem after having done too much work locally.


___
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] Progress report of Fossil 2.x

[Tony Papadimitriou]

-Original Message- 
From: Warren Young


On Mar 1, 2017, at 2:03 AM, Tony Papadimitriou <to...@acm.org> wrote:

My 'prediction' is that two versions will end up in a similar mess to the 
Python 2.7 vs Python 3.x one.


[all irrelevant Python analysis removed]

I was referring to the fact that Python is divided into two communities with 
no foreseeable deadline for the discontinuance of Python 2.7 in favor of 
3.x.
Those loyal to 2.7 and those loyal to 3.x (like myself).  But regardless of 
which group one belong to, one still needs to keep two installations to cope 
with the various applications or libraries depending on whether those are 
written for Python 2.7 or 3.x


Having two fossils (which is how I understood the plan), one for each case 
(SHA1 and SHA3) may lead to a similar situation.  Why?
For example, if I keep my own repos in SHA3 (which I'm for BTW), but I also 
have to interact with 3rd party sites (like chiselapp) some of which may 
choose to remain with SHA1 compatible, I would have to keep two different 
fossils to cope with each case.  Which means I need to remember where to use 
what.


And, having to remember which version to use depending on the other side 
being compatible or not, will be a practical nuisance.
drh has already said the new versions will warn you when you’re about to 
run into a conflict.


A warning may tell me that I'm using the wrong one, but I would still have 
to try it first before I get the warning.  This is annoying.  You see now, 
if I want to access a git repo, I use git.  But if I want to access a fossil 
repo I will have doubt as to whether to use fossil 2 or fossil 2.1 until 
after I use one and either get lucky or be warned to use the other version.


Even my open check-outs all over my disk.  Which one I opened with 2 and 
which with 2.1?


Would it not be possible to have a single version that simply keeps an 
extra table with the SHA3 and the presence of the table alone will 
determine which way to go?


Certainly. But every binary configuration option potentially doubles the 
size of the test space.  Every existing test has to run in all possible 
configurations.

So, who will do that work, and why?
I’m not asking why you want the work done, I’m asking why that person would 
do it for you, if it is not you doing the work for your own benefit.  What 
itch is that person scratching?


I believe DRH asked for feedback.  And that was my feedback.  Whether it is 
agreeable with you is irrelevant.  I am not a fossil developer and do not 
plan to become one.
If fossil developers do not care for non-developer feedback they shouldn't 
ask for it.  Or, if by providing feedback I'm somehow bound to implement it, 
I should be told about it not to waste my time.


___
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] Progress report of Fossil 2.x

[Tony Papadimitriou]

My 'prediction' is that two versions will end up in a similar mess to the 
Python 2.7 vs Python 3.x one.


Also, Fossil 2.0 will not be able able to get any significant updates due to 
version collision with 2.1 (so, maybe 2.0 and 3.0 -- oops, more like 
Python!)


And, having to remember which version to use depending on the other side 
being compatible or not, will be a practical nuisance.


Would it not be possible to have a single version that simply keeps an extra 
table with the SHA3 and the presence of the table alone will determine which 
way to go?


BTW, you would not even need to expose SHA3 to the end user, only use it 
internally for verification -- only difference is that you have to accept 
SHA1 collisions but not SHA3 (or other) collisions.
The alternate hash could really be anything (from the available choices) the 
user chooses -- even possibly let the user write their own plugins to make 
their repos truly personal as no one without the same hash method will be 
able to commit to it.


My 0.01 eurocent.

-Original Message- 
From: Richard Hipp

Sent: Wednesday, March 01, 2017 4:24 AM
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] Progress report of Fossil 2.x

Discussion of Fossil 2.x continues on the fossil-dev mailing list.  I
am offering this update to the broader fossil-users community to
elicit feedback.

(1) Moving forward, Fossil repositories will be able to name artifacts
using either the legacy SHA1 hash or using a SHA3-256 hash.  Both
hashes can be used within the same repository.  Long running projects,
such as SQLite, can continue forward without changing any existing
hash values yet still use SHA3 names for new content

(2) For most display purposes, the 64-digit SHA3-256 hash will be
truncated to the same 40-character length as a SHA1 hash.  Most users
will probably never notice that a hash algorithm change has occurred.
The full 256-bit hash will be carried internally for collision
detection, and will be accessible on some detailed UI screens.

(3) To facility trouble-free upgrades, there will be a simultaneous
release of Fossil 2.0 and Fossil 2.1.

(4) Fossil 2.0 will be fully compatible with Fossil 1.x.  No "fossil
rebuild" is needed.  Just drop the new executable on your $PATH and
continue typing fossil commands just like you always have.  Fossil 2.0
will sync and clone with Fossil 1.x and will read and write all the
same repository files as Fossil 1.x.  The are completely
interchangeable.  The only difference is that Fossil 2.0 understands
SHA3 hashes whereas Fossil 1.x does not.  But Fossil 2.0 does not
generate any SHA3 artifacts so it will not do anything to confuse
Fossil 1.x.

(5) Fossil 2.1 is almost identical to Fossil 2.0.  The only difference
is that Fossil 2.1 always uses SHA3 names for new content.  Thus
Fossil 2.1 will generate artifacts that Fossil 1.x does not know how
to interpret.  And Fossil 2.1 will have difficulty syncing with Fossil
1.x.  But Fossil 2.0 and Fossil 2.1 will interoperate seamlessly.

(6) The upgrade process goes like this:  First begin deploying Fossil
2.0 everywhere within the organization.  Once Fossil 2.0 is deployed
everywhere, then go back and start deploying Fossil 2.1 everywhere.
As long as nobody tries to use Fossil 2.1 until after everyone has
stopped using Fossil 1.x, no incompatibilities will be occur and
everything should continue to operate normally.

(7) After Fossil 2.1 is deployed, all new content will use SHA3 hashes
exclusively.  Older content will continue to be named by the legacy
SHA1 hashes so existing hyperlinks and command line arguments will
continue to work just as if no hash algorithm change had ever
occurred.

(8) The above is just a plan.  Everything is subject to change.

(9) Your feedback is encouraged and appreciated.
--
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] Proposed roadmap for Fossil 2.0

[Tony Papadimitriou]

-Original Message- 
From: Warren Young

On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou <to...@acm.org> wrote:

how is it possible for someone to inject a 'bad' file with the same SHA1 
as a 'good' file already in the repo?
Your attacker could be MITM’d into the sync stream.  I gave an example 
requiring only the current SHA-1 collision technology in my first reply in 
the other thread:


So now HTTPS is also broken?


The only ways I can imagine
That’s because you aren’t a highly motivated, highly resourced, highly 
trained black hat.  But such people do exist.


I was implying 'practical' ways, not theoretical.  Now, if Google wants to 
use its billions to break my repo, they may do it, but it would be easier 
for them to try to buy it from me for much less!
So, do you actually know of some other practical ways, or just looking to 
make conversation?


I believe it will be really-really difficult (for the foreseeable future 
at least) for someone to come up with a 'bad' file with both SHA1 and MD5 
being the same.
Given that an MD5 collision costs less than 65 cents US to create these 
days,[3] I think your premise is flawed.
You think, I think, who cares?  Can you prove your point by providing such a 
collision while we're still alive?


Yes, creating a collision in both MD5 and SHA-1 is probably more expensive 
than the addition of the two (US $10.65) but I don’t think you can say 
that MD5 is adding meaningful security here.

MD5 is broken, broken, broken.[4]


So, if I give you a random piece of source code you (or your rich friends) 
can create a matching paired-SHA1-MD5 alternate version (while we're still 
alive)?

You would probably make bigger headlines than Google is making right now.


One would still need to match both SHA1 and MD5 to inject -- not easy!



Argument from incredulity.[5]

Ditto! (Or prove how easy it is!)

may introduce (an avalanche[?] of) bugs, and possibly even risk the 
integrity of our current repos until fully bug-free.
Have avalanches of bugs been a notable hallmark of Fossil and SQLite, in 
your experience?
Past success rates do not guarantee future ones (slightly modified from a 
bank fine print warning).


(I for one would be reluctant to try it for actual work until enough 
other people have used it for some time without problems.)
That’s why the SQLite project dogfoods trunk Fossil, and drh encourages us 
end users to use Fossil from trunk, too.  By the time Fossil 2.0 is 
released, it *will* be well-tested, both formally and informally.
Actually, it's quite common that trunk fossil uses alpha and beta versions 
of SQLite3 for the benefit of test-driving SQLite3.  So, regardless any 
assurances to the contrary, it's still a bit risky.


you can't really get the whole population to switch at the exact same 
time.

We have decades of experience managing such problems.

But ... you are so Young. :)

Less arrogant people with decades of experience also created MD5, SHA1, ... 
Not a very comforting argument at this point, is it?


___
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] Proposed roadmap for Fossil 2.0

[Tony Papadimitriou]

Leaving aside for a moment the consequences in general of the presumed 
imminent SHA1 collapse (and some of the valid points already made by Linus 
regarding Git):


If FOSSIL will refuse (and I actually tried it with those two same SHA1 
PDFs) to accept a file (commit, push, pull) with the same SHA1 as any of 
those already in the repo (not sure about the unversioned case, however), 
how is it possible for someone to inject a 'bad' file with the same SHA1 as 
a 'good' file already in the repo?


The only ways I can imagine (and please add more if you see them) are:

* Deconstruct the repo, replace the specific file(s) with the 'bad' one(s) 
and reconstruct.  But, this would be in the user's local copy, and s/he 
would not be able to push those changes to the other side (again, because 
the given SHA1 already exists, and the file with the same SHA1 will not be 
retransmitted/reloaded).  The injection will not propagate beyond the 
attacker's machine.


* Know the 'good' file before it's actually committed, prepare a 'bad' same 
SHA1 replacement, and commit it before the 'good' has a chance, locking it 
out.  (Rather impossible even for clairvoyant people -- and even if, it 
would most likely be noticed more easily than replacing a dormant file 
nobody bothers with!)


* Be the administrator of a site (like chiselapp for example -- I do not 
mean to insinuate anything, I simply do not know of another public example) 
and go through the deconstruct-replace-reconstruct process replacing good 
with bad.  This is the only scenario I see which will affect the general 
public -- specifically, those cloning the injected repo from scratch. 
However, this again (because of no same SHA1 reloading) will not affect the 
local copies of the contributors, when pulling/syncing -- or any of the 
clones done before the injection.  This is the only one I would worry about 
at a theoretical level.


So, unless my assumptions above are incorrect, how urgent is the need to 
transition away from SHA1?


Also, the two example PDF files with the same SHA1 still have different MD5 
which fossil apparently already uses, and this (MD5) could be used as an 
alternate verifier for each artifact without changing anything else.  I 
believe it will be really-really difficult (for the foreseeable future at 
least) for someone to come up with a 'bad' file with both SHA1 and MD5 being 
the same.  Don't tell me MD5 is broken.  One would still need to match both 
SHA1 and MD5 to inject -- not easy!


I'm certainly not against transitioning to a more secure hash *eventually* 
but I doubt there is such an immediate need (until the Easter deadline, for 
example) for making what seems to be a rather serious update that (and this 
my biggest concern) may introduce (an avalanche[?] of) bugs, and possibly 
even risk the integrity of our current repos until fully bug-free.  (I for 
one would be reluctant to try it for actual work until enough other people 
have used it for some time without problems.)  So, I think it could be done 
in a more relaxed timeframe that will also give time to brainstorm the best 
possible general solution that will work easily even in the event of another 
hash function replacement in the future (e.g., what if SHA3 is already being 
prepped by Google for summer announcement?) while maintaining backwards 
compatibility to the greatest extent possible.  It's also interesting to 
take some time to see how others will try to deal with this problem and get 
ideas.


As for the proposal, although it sounds OK on first reading, the 'unknowns' 
are a bit worrisome, particularly the syncing between different versions --  
you can't really get the whole population to switch at the exact same time.


And, I'm not sure it's the minimum (i.e., less chance for new bugs) solution 
possible.  I believe the example I gave with the MD5 is safe enough 
temporary 'hack' for the foreseeable future with less possibility of bugs as 
it will not switch to a new hash, simply use the second one for extra 
verification (and it doesn't have to be MD5, you can use SHA3 but in a 
similar context -- simply MD5 is already there).


My 0.01 eurocent!

___
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] Unversioned files not accessible from Webinterface

[Tony Papadimitriou]

Thank you for the tip, good to know.
(However, I think my point is still valid.  Unless the repo visitor happens to 
magically know about this /uvlist link there seems to be no obvious way to get 
to it starting navigation from some main page.)
From: Martin Gagnon 

To see the list of unversioned files on a repo, use the /uvlist page: 
example: https://www.fossil-scm.org/index.html/uvlist
___
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] Bug in "fossil branch new"

[Tony Papadimitriou]

Hmm, but isn't it usually the newbies that do NOT read any documentation? :)

However, if this gets implemented here's a somewhat crazier thought to make 
it ever better for the general public:


fossil set newbie-mode = 

where  is blank indicating "I don't know what I'm supposed to be doing 
here" so fossil will print the whole manual for each command together with 
relevant Wikipedia links as to what an SCM is good for along with real-life 
examples of success stories,
or  is 'youtube' where all help is made of video clips of the 
corresponding concepts or command actions,
or  is 'gui' for the command-line impaired where the command-line 
interface will be completely disabled and everything will be possible from 
the GUI,
or  is 'git' indicating I come from the git world and I refuse to 
learn fossil so I want all commands to show me the git equivalent way,  or 
even better, fossil should accept git commands directly,
or  is 'expert' indicating that all help should be single-liners 
referring to all commands and options with their minimum required text and 
describing all actions with just mathematical symbols,
or  is 'false' for keeping it the way it is now (merely for backwards 
compatibility as I'm sure the majority will want to switch to one of the new 
fancier modes),

... space reserved for additional brainstorming ...

(Now, I hope nobody took this seriously.)

-Original Message- 
From: Richard Hipp


Here is a crazy, crazy thought:

Suppose we put lots and lots of extra text on many of the Fossil
commands, explaining
what just happened and the current repository state, after every
command.  Then provide a command like:

fossil set newbie-hints off --global

That will turn off all the extra verbiage after users get comfortable
with the system.
--
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] Bug in "fossil branch new"

[Tony Papadimitriou]

+1

This would also guard against unplanned/accidental use of same branch name 
in a repo with tens of older inactive branches one cannot possible remember 
at all times.


-Original Message- 
From: Richard Hipp

Sent: Monday, February 06, 2017 6:18 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Bug in "fossil branch new"

On 2/6/17, Richard Hipp  wrote:


That is correct, and it is by design.  Fossil allows any number of
branches to share the same name.


On second thought, perhaps it would be worthwhile to enhance Fossil so
that it issued a warning if you include a --branch argument on "fossil
commit" with the same name as an existing open branch, and actually
fail the commit unless the --force flag is also present.  Perhaps such
a change would make Fossil easier to transition to from other systems.
Does anybody else having any feelings one way or another about this?
--
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

[fossil-users] Feature request - SEARCH to honor the -R option

[Tony Papadimitriou]

Would it be possible for SEARCH to honor the –R option (just like TIMELINE 
does) so that one can search without having to open the repo?

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FOSSIL crashes with PDFs!!!

[Tony Papadimitriou]

When I attempted to PULL with the command FOSSIL PULL –R FILE
but (by mistake of course) I pointed it instead to a PDF file, I got an endless 
loop that ends with a crash. (Win7 machine.)
It happens with any recent version of FOSSIL I tried.

And it seems pretty much any PDF file will cause this behavior.  With other non 
DB files I simply get a ‘no database’ error message.

Here’s some of the output:

SQLITE_NOTADB: file is encrypted or is not a database
fossil: file is encrypted or is not a database
SELECT value FROM config WHERE name='allow-symlinks'
SQLITE_NOTADB: file is encrypted or is not a database
fossil: file is encrypted or is not a database
PRAGMA database_list
SQLITE_NOTADB: file is encrypted or is not a database
fossil: file is encrypted or is not a database
PRAGMA database_list
SQLITE_NOTADB: file is encrypted or is not a database
fossil: file is encrypted or is not a database
PRAGMA database_list
SQLITE_NOTADB: file is encrypted or is not a database
fossil: file is encrypted or is not a database
PRAGMA database_list___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Possible bug with the TIMELINE under some conditions

[Tony Papadimitriou]

I noticed that when a filter is applied to the timeline (such as ‘parent 
current’), AND the –p option is used to filter for a specific file, then the –n 
option (implicit or explicit) seems to count entries towards the limit 
regardless of whether these are displayed or not.  The result is you pretty 
much have to guess what number to use to get enough entries displayed.

To see what I’m talking about try the following with the sqlite3 repo:

fossil tim -p src\shell.c p current

(I think –n defaults to 20.) I get just 1 entry.  Now try:

fossil tim -p src\shell.c p current -n 50

I get just 4 entries.  But with –n 0 (unlimited) I get 885.

This happens with at least v1.36 [65e69b8dd8] and v1.37 [6f3ec1bef6].

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] error in commit

[Tony Papadimitriou]

The following steps should work assuming you haven't added any more commits
after the mistake (and haven't pushed your changes anywhere else).  Also,
your current checkout is the one with the mistake (if not, first do F UP to
the appropriate check-in):

f co prev --keep
f pur ch tip
f com file1 file2 file3 ...
f pur o 1
f reb

(where f = fossil)
First line goes back one check-in without changing any of your files on
disk.
Second line purges the mistake (and gives a number -- usually 1 if no more
purges pending -- use this number later)
Third line commits the files you meant to commit (file1 file2 file3 ...)
Fourth line completely kills the purged content from the repo (use the
number you got in step 2)
Final line rebuilds the repo and removed the purged content.

I get into this situation often, and these steps (if done right after the
mistake -- and not many actions later) work well.

(If anyone has a quicker method, please enlighten us.)

-Original Message- 
From: Aldo Nicolas Bruno

Sent: Monday, December 05, 2016 11:44 PM
To: Fossil SCM user's discussion
Subject: Possible Spam(10.041):[fossil-users] error in commit

Hi,
By mistake I've made an error and did fossil commit -m "added lalal"
without specifying which files to commit, so it commited all the changed
files... but my intention was to commit only some files...
There is a way to elegantly undo the commit or modify it so as to
exclude some files?
Thanks
Aldo
___
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] error in commit

[Tony Papadimitriou]

The following steps should work assuming you haven't added any more commits 
after the mistake (and haven't pushed your changes anywhere else).  Also, 
your current checkout is the one with the mistake (if not, first do F UP to 
the appropriate check-in):


f co prev --keep
f pur ch tip
f com file1 file2 file3 ...
f pur o 1
f reb

(where f = fossil)
First line goes back one check-in without changing any of your files on 
disk.
Second line purges the mistake (and gives a number -- usually 1 if no more 
purges pending -- use this number later)

Third line commits the files you meant to commit (file1 file2 file3 ...)
Fourth line completely kills the purged content from the repo (use the 
number you got in step 2)

Final line rebuilds the repo and removed the purged content.

I get into this situation often, and these steps (if done right after the 
mistake -- and not many actions later) work well.


-Original Message- 
From: Aldo Nicolas Bruno

Sent: Monday, December 05, 2016 11:44 PM
To: Fossil SCM user's discussion
Subject: Possible Spam(10.041):[fossil-users] error in commit

Hi,
By mistake I've made an error and did fossil commit -m "added lalal"
without specifying which files to commit, so it commited all the changed
files... but my intention was to commit only some files...
There is a way to elegantly undo the commit or modify it so as to
exclude some files?
Thanks
Aldo
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Merge failed with SQL error

[Tony Papadimitriou]

Just to report some unexpected problem that happened today.

After adding (ADD command) some files to trunk that where already part of a 
different branch, and committing, I went to the other branch in question (with 
UPDATE) and tried to MERGE trunk to include some other changes as well.  Here’s 
what I got (multiple WARNINGs have been collapsed to just one, and the actual 
filenames removed):

c:\temp>f me trunk
WARNING: no common ancestor for ...several_files...
SQLITE_CONSTRAINT: abort at 45 in [INSERT INTO 
vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname)  SELECT 
6938,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=551448]: UNIQUE 
constraint failed: vfile.pathname, vfilef: UNIQUE constraint failed: 
vfile.pathname, vfile.vid: {INSERT INTO 
vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname)  SELECT 
6938,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=551448}

DB –DB-CHECK shows no problems.

(I ended up purging the commit for now because it felt like the repo may have 
gotten into an unstable state.)

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FOSSIL STASH behavior

[Tony Papadimitriou]

When doing STASH GO the check out is first updated to the baseline and then the 
stash changes applied.

However, if a following UNDO is given, only the applied stash changes are 
reverted.  The baseline does not return to where it was before the STASH GO 
command.

I don’t know if this is by design or an oversight, but it seems wrong to me 
given that UNDO should undo every action of the previous command, not just part 
of it, right?

This is fossil version 1.36 [65e69b8dd8] 2016-10-24 18:15:07 UTC
Compiled on Nov 11 2016 23:02:22 using msc-18.00 (32-bit)
SQLite 3.15.1 2016-11-04 12:08:49 1136863c76
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2j  26 Sep 2016)
UNICODE_COMMAND_LINE
STATIC_BUILD

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] UNVERSIONED issues

[Tony Papadimitriou]

* For consistency, could you please add a DELETE alias to the REMOVE/RM 
subcommand of the UNVERSIONED command?  (I’m used to doing DEL and it’s 
confusing to have to switch to REM for UNVERSIONED.)

* Would it be possible to also display the timestamp (real or –-mtime) of the 
files when doing a LIST subcommand?
  This helps to quickly verify if the latest (or whatever one needs) version is 
the one actually stored.  Without it, only choice is to re-load (ADD) each file 
you’re not sure about.

* Windows paths should be allowed with either forward or backward slashes, 
again for consistency to how most Windows apps work.

Thank you.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is there a quick way to SHUN all version of a given filename?

[Tony Papadimitriou]

With the introduction of the new UNVERSIONED command, I thought there is no 
longer need to keep certain binary images in the check-out as versioned files.
Instead, I want to keep only the latest version as unversioned files.

To remove all the versioned ones, is there is a simple way?  Perhaps, and SQL 
command to place all filenames that match a pattern to the to-be-shunned table?

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] More compilation problems with latest trunk

[Tony Papadimitriou]

Possibly! Apparently, a different version of sqlite3.c was somehow left in 
the checkout.  (It's already 2nd time I get bitten by this.)

I tried again with the current trunk and there was no problem.

I guess I'll have to update my script to do a REVERT right after the UPDATE 
command to cancel any possible left-over changes.


Sorry for the noise!

-Original Message- 
From: Richard Hipp

Sent: Saturday, November 05, 2016 2:02 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] More compilation problems with latest trunk

Works fine for me.
https://www.fossil-scm.org/fossil/info/9c211011190bde9a compiled with
either mingw32 or msvc2015.

Maybe you have a bad merge in your check-out.  What does "fossil
changes" or "fossil diff" show?

On 11/5/16, Tony Papadimitriou <to...@acm.org> wrote:

..\src\sqlite3.c(132731) : error C2143: syntax error : missing ';' before
'<<'
..\src\sqlite3.c(132758) : error C2143: syntax error : missing ')' before
'->'
..\src\sqlite3.c(132758) : error C2143: syntax error : missing '{' before
'->'
..\src\sqlite3.c(132758) : error C2059: syntax error : '->'
..\src\sqlite3.c(132758) : error C2059: syntax error : ')'
..\src\sqlite3.c(132760) : error C2059: syntax error : 'type'
..\src\sqlite3.c(132761) : error C2059: syntax error : 'for'
..\src\sqlite3.c(132761) : error C2143: syntax error : missing '{' before
'<'
..\src\sqlite3.c(132761) : error C2059: syntax error : '<'
..\src\sqlite3.c(132761) : error C2143: syntax error : missing '{' before
'++'
..\src\sqlite3.c(132761) : error C2059: syntax error : '++'
..\src\sqlite3.c(132761) : error C2059: syntax error : ')'
..\src\sqlite3.c(132850) : error C2143: syntax error : missing '{' before
'->'
..\src\sqlite3.c(132850) : error C2059: syntax error : '->'
..\src\sqlite3.c(132851) : error C2371: 'whereInfoFree' : redefinition;
different basic types
..\src\sqlite3.c(129702) : see declaration of 'whereInfoFree'
..\src\sqlite3.c(132852) : error C2059: syntax error : 'return'
..\src\sqlite3.c(132853) : error C2059: syntax error : '}'
..\src\sqlite3.c(133154) : error C2079: 'yy354' uses undefined struct
'LimitVal'
..\src\sqlite3.c(135436) : error C2224: left of '.pLimit' must have
struct/union type
..\src\sqlite3.c(135436) : error C2224: left of '.pOffset' must have
struct/union type
..\src\sqlite3.c(135436) : error C2198: 'sqlite3SelectNew' : too few
arguments for call
..\src\sqlite3.c(135652) : error C2224: left of '.pLimit' must have
struct/union type
..\src\sqlite3.c(135652) : error C2224: left of '.pOffset' must have
struct/union type
..\src\sqlite3.c(135655) : error C2224: left of '.pLimit' must have
struct/union type
..\src\sqlite3.c(135655) : error C2224: left of '.pOffset' must have
struct/union type
..\src\sqlite3.c(135658) : error C2224: left of '.pLimit' must have
struct/union type
..\src\sqlite3.c(135658) : error C2224: left of '.pOffset' must have
struct/union type
..\src\sqlite3.c(135661) : error C2224: left of '.pOffset' must have
struct/union type
..\src\sqlite3.c(135661) : error C2224: left of '.pLimit' must have
struct/union type
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio

12.0\VC\BIN\cl.EXE"' : return code '0x2'



--
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

[fossil-users] More compilation problems with latest trunk

[Tony Papadimitriou]

..\src\sqlite3.c(132731) : error C2143: syntax error : missing ';' before '<<'
..\src\sqlite3.c(132758) : error C2143: syntax error : missing ')' before '->'
..\src\sqlite3.c(132758) : error C2143: syntax error : missing '{' before '->'
..\src\sqlite3.c(132758) : error C2059: syntax error : '->'
..\src\sqlite3.c(132758) : error C2059: syntax error : ')'
..\src\sqlite3.c(132760) : error C2059: syntax error : 'type'
..\src\sqlite3.c(132761) : error C2059: syntax error : 'for'
..\src\sqlite3.c(132761) : error C2143: syntax error : missing '{' before '<'
..\src\sqlite3.c(132761) : error C2059: syntax error : '<'
..\src\sqlite3.c(132761) : error C2143: syntax error : missing '{' before '++'
..\src\sqlite3.c(132761) : error C2059: syntax error : '++'
..\src\sqlite3.c(132761) : error C2059: syntax error : ')'
..\src\sqlite3.c(132850) : error C2143: syntax error : missing '{' before '->'
..\src\sqlite3.c(132850) : error C2059: syntax error : '->'
..\src\sqlite3.c(132851) : error C2371: 'whereInfoFree' : redefinition; 
different basic types
..\src\sqlite3.c(129702) : see declaration of 'whereInfoFree'
..\src\sqlite3.c(132852) : error C2059: syntax error : 'return'
..\src\sqlite3.c(132853) : error C2059: syntax error : '}'
..\src\sqlite3.c(133154) : error C2079: 'yy354' uses undefined struct 'LimitVal'
..\src\sqlite3.c(135436) : error C2224: left of '.pLimit' must have 
struct/union type
..\src\sqlite3.c(135436) : error C2224: left of '.pOffset' must have 
struct/union type
..\src\sqlite3.c(135436) : error C2198: 'sqlite3SelectNew' : too few arguments 
for call
..\src\sqlite3.c(135652) : error C2224: left of '.pLimit' must have 
struct/union type
..\src\sqlite3.c(135652) : error C2224: left of '.pOffset' must have 
struct/union type
..\src\sqlite3.c(135655) : error C2224: left of '.pLimit' must have 
struct/union type
..\src\sqlite3.c(135655) : error C2224: left of '.pOffset' must have 
struct/union type
..\src\sqlite3.c(135658) : error C2224: left of '.pLimit' must have 
struct/union type
..\src\sqlite3.c(135658) : error C2224: left of '.pOffset' must have 
struct/union type
..\src\sqlite3.c(135661) : error C2224: left of '.pOffset' must have 
struct/union type
..\src\sqlite3.c(135661) : error C2224: left of '.pLimit' must have 
struct/union type
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\cl.EXE"' : return code '0x2'___
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] Error compiling FOSSIL trunk

[Tony Papadimitriou]

Yes, it works now. Thanks!
(The fix has a minor typo: Dupliate => Duplicate)

-Original Message- 
From: Richard Hipp 
Sent: Wednesday, November 02, 2016 7:49 PM 
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Error compiling FOSSIL trunk 

On 11/2/16, jungle Boogie <jungleboog...@gmail.com> wrote:
> On 2 November 2016 at 09:33, Tony Papadimitriou <to...@acm.org> wrote:
>> c:\fossil\win\winhttp.h(24) : error C2004: expected 'defined(id)'
>> c:\fossil\win\winhttp.h(24) : fatal error C1012: unmatched parenthesis :
>> missing ')'
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio
>> 12.0\VC\BIN\cl.EXE"' : return code '0x2'
>> Stop.
>>
>
> getting the same failure with MSVC 2010 but unix builds pass fine.
>

Should be fixed now.
-- 
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

[fossil-users] Error compiling FOSSIL trunk

[Tony Papadimitriou]

c:\fossil\win\winhttp.h(24) : error C2004: expected 'defined(id)'
c:\fossil\win\winhttp.h(24) : fatal error C1012: unmatched parenthesis : 
missing ')'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is FOSSIL supposed to compile with MSVC14?

[Tony Papadimitriou]

I can compile fossil just fine (with or without SSL) with MSVC12
I just installed MSVC14 and I get errors when compiling with the SSL option (no 
errors without it).

(BTW, SQLite3 also compiles OK with MSVC14).

So, I wonder if this is normal, or if I should be looking for installation / 
configuration problems in my setup.

Here’s the warnings/errors I get:

zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _free imported in 
function _zcfree
zlib.lib(gzlib.obj) : warning LNK4049: locally defined symbol _free imported
zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _malloc imported 
in function _zcalloc
zlib.lib(gzlib.obj) : warning LNK4049: locally defined symbol _malloc imported
zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol 
___stdio_common_vsprintf imported in function __snprintf
zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol __wopen imported 
in function _gz_open
zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol __lseeki64 
imported in function _gz_open
OLDNAMES.lib(open.obi) : warning LNK4049: locally defined symbol __open imported
libeay32.lib(pem_lib.obj) : error LNK2001: unresolved external symbol 
___iob_func
libeay32.lib(txt_db.obj) : error LNK2001: unresolved external symbol ___iob_func
libeay32.lib(ui_openssl.obj) : error LNK2001: unresolved external symbol 
___iob_func
ssleay32.lib(t1_enc.obj) : error LNK2001: unresolved external symbol ___iob_func
ssleay32.lib(d1_both.obj) : error LNK2001: unresolved external symbol 
___iob_func
ssleay32.lib(s3_srvr.obj) : error LNK2001: unresolved external symbol 
___iob_func
libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
___iob_func
libeay32.lib(dso_win32.obj) : error LNK2019: unresolved external symbol 
_sprintf referenced in function _win32_name_converter
zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol __imp__wcstombs 
referenced in function _gz_open
zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol __imp__open 
referenced in function _gz_open
OLDNAMES.lib(open.obi) : error LNK2001: unresolved external symbol __imp__open
.\fossil.exe : fatal error LNK1120: 4 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.

Thanks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] New UNVERSIONED command does not recognize backward slashes under Windows

[Tony Papadimitriou]

This is fossil version 1.36 [65e69b8dd8] 2016-10-24 18:15:07 UTC
Compiled on Oct 29 2016 19:57:38 using msc-18.00 (32-bit)
SQLite 3.15.0 2016-10-14 10:20:30 707875582f
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2j  26 Sep 2016)
UNICODE_COMMAND_LINE
STATIC_BUILD

Just to bring to your attention (if not already known) that the new UNVERSIONED 
command does not recognize backward slashes (\) in paths, under Windows.  
Although I prefer typing forward slashes, and so accepting forward slashes 
should be retained, I sometimes take a list of files from a another command, 
and these come with a backward slash instead, needing further processing to 
convert from \ to / to be accepted by FOSSIL.

Example:
f unv add bin\name
does not work
f unv add bin/name
works fine.

Also, I would expect
f unv add bin
to recursively add all files inside the bin subdirectory but it does not seem 
to work, resorting to a more tedious addition of each file separately.

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] Compilation error with latest trunk

[Tony Papadimitriou]

Usually do just FOSSIL UPDATE and then run make.  Now re-opened checkout and 
tried again, no problems! Thanks.


-Original Message- 
From: Richard Hipp

Sent: Monday, September 19, 2016 9:41 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Compilation error with latest trunk

On 9/19/16, Tony Papadimitriou <to...@acm.org> wrote:

manifest_.c:2631: extra '#endif'.
tar_.c:708: Unterminated "{"
Errors while processing "tar_.c"
NMAKE : fatal error U1077: '.\makeheaders.exe' : return code '0x2'
Stop.


I'm unable to reproduce the problem on Windows10.

* Fresh Fossil checkout
* cd win
* nmake /f makefile.msc fossil.exe

Compiles without error or warnings.  Resulting binary works great.

--
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

[fossil-users] Compilation error with latest trunk

[Tony Papadimitriou]

manifest_.c:2631: extra '#endif'.
tar_.c:708: Unterminated "{"
Errors while processing "tar_.c"
NMAKE : fatal error U1077: '.\makeheaders.exe' : return code '0x2'
Stop.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Default number of lines for console TIMELINE display

[Tony Papadimitriou]

Rather than having an arbitrary fixed (20) default number of timeline entries 
that get displayed with the console TIMELINE command, wouldn’t it be better to 
have this number auto-adjust based on the actual number of rows the display 
has.  The default seems to be suitable for the classic 80x25 displays but 
larger arbitrary sizes (e.g., resizable windows) are common these days both for 
Windows and Linux.

(It could even be smarter and also account for the width...)

It would be nice for the default timeline screen (no –n option) to cover no 
less than 90% of the display whatever its size happens to be.  (Now, in my 
case, it’s less than half, and I could see a lot of entries but I have to 
constantly give the –n option for that.)

Just a thought. Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] BISECT LOG displays UTC date/time even though timeline is set to local date/time

[Tony Papadimitriou]

This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC

It’d be less confusing if BISECT displayed the date/time the same way as the 
current timeline setting.

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] FOSSIL does not push edit comment changes, is this normal?

[Tony Papadimitriou]

I tried to reproduce the general sequence of actions on a fresh repo but I 
can't seem to repeat the problem.


However, it does it consistently on my end for this one repo.  I'm keeping a 
'frozen' backup of these two files (local and remote) for future 
investigation, if possible at a later time.  You know, like cryonics ... in 
hopes of finding a future cure :)


So, I guess that's one yet unfortunate test case because I can not possibly 
give it as is with the actual source code content (the comments and other 
peripheral info I do not care about).


Is there some way (via SQL) to delete just the file contents (I only need to 
blank or garble the content for certain file extensions that represent 
proprietary code -- many files) and then I can send you

the repo database so you can check its state, if this might help?

I realize there will be tons of warnings opening the now 'malformed' repo in 
order to attempt the push, but it may still be good enough for you to see 
the problem on your end.  I don't know.
So, if there is a way to obscure the file contents, and I can still 
reproduce it here on the 'dummy' repo files, I'll send them to you for 
examination.
(I suppose this is a somewhat common issue with sharing non-public repos for 
troubleshooting, so maybe you already know of a way to do this.)


-Original Message- 
From: Richard Hipp

Sent: Friday, June 17, 2016 5:15 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FOSSIL does not push edit comment changes,is 
this normal?


On 6/17/16, Tony Papadimitriou <to...@acm.org> wrote:

This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC

After editing a couple of check-in comments, I did ‘push’ and saw zero
artifacts sent.  Here’s the output:

I don’t think this is expected behavior, is it?  If not, what could be the
problem?



It is not expected behavior.  Comment changes should always be pushed.
Do you have a reproducible test case?

--
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

[fossil-users] FOSSIL does not push edit comment changes, is this normal?

[Tony Papadimitriou]

This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC

After editing a couple of check-in comments, I did ‘push’ and saw zero 
artifacts sent.  Here’s the output:

Push to file://E:/db/xxx.fossil
Round-trips: 1   Artifacts sent: 0  received: 0
Push done, sent: 281962  received: 12407  ip:

I tried again and again with the same results.

This made me check the remote repo and, indeed, I did not see the comment edits.
Doing a ‘tim –R e:\db\xxx.fossil’ shows the same final check-in as the local 
repo.  So, only the following two edits are missing.

(The edits were done from the command with the ‘f am check-in –e’ command.)

Running ‘db –db-check’ on either repo says ok.

The only obvious difference I can see is that the remote repo still has a 
private branch which has been purged (and rebuilt) on the local repo but not on 
the remote.
(However, that branch is unrelated to the edits, obviously, or I couldn’t have 
done them – on a purged branch.)

I don’t think this is expected behavior, is it?  If not, what could be the 
problem?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Minor (G)DIFF issue

[Tony Papadimitriou]

Hello,

In doing FOSSIL –GDIFF between two check-ins using the –FROM and –TO option of 
the command,
I’m shown the files (left and right window in WinDiff) with auto-generated temp 
filenames at the top for each side, respectively.

This makes it impossible to know which files I’m looking at, unless I have this 
information also as part of the file.

I suppose FOSSIL extracts the files to compare using temp filenames 
automatically generated.  Would it possible to prepend the actual filename so 
that instead of “skldfjgnksdjfgnsdfg”  (sample temp filename) I get this 
“actual_filename_skldfjgnksdjfgnsdfg” (actual together with temp)
to help know which files I’m dealing with at the moment?

Note: This is on Windows – not sure if a similar issue also appears under Linux.
This is fossil version 1.35 [72df287cf3] 2016-06-11 20:13:22 UTC

Strangely, if I use only the –FROM option, this problem does not exist.

Thank you.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] SET option usability bug

[Tony Papadimitriou]

When giving the set command to change some option and you’re outside an open 
repo directory, the global setting is affected instead, even though the 
–-global option is not given.

So, one can very easily mess up their global setup by accidentally attempting 
to set a local option but either from the wrong directory or from right 
directory but with the repo being closed at the moment.

I think the –-global option should be required at all times to change the 
global version of the option as a safeguard against these kinds of mistakes.

Besides, the help screen seem to imply the same by not being clear about what 
happen when a repo is not open.

Options:
  --global   set or unset the given property globally instead of
 setting or unsetting it for the open repository only.

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] Branch and tag metadata

[Tony Papadimitriou]

I've had the same wish for a long long time.  I would like the FOSSIL BRANCH 
list to show except for the branch name some kind of description.
Like you mentioned, making the branch name itself long enough would be one 
way to tackle this but it is counter-productive as you would need to type 
the whole thing each time you need to access that branch.


So, I think the simplest way to add this functionality *without* causing 
backward compatibilities or file format changes is to display the first 
commit comment for that particular branch as a description in the BRANCH 
list command.


Although it may not always be the most accurate description for branches 
already created, I think in most cases the first branch commit comment 
represents a pretty good description about what the branch is about, or why 
it had to be created.


My €0.02

Another wish is for the BRANCH list to show if a branch is private.  This 
would be very helpful to me (at least).


Add another €0.01

-Original Message- 
From: Andy Goth

Sent: Saturday, May 21, 2016 5:39 AM
To: Fossil Users Mailing List
Subject: [fossil-users] Branch and tag metadata

I'm thinking I might want the ability to describe branches and tags
separate from the check-in comments.
...
But creating a space to provide a short description (akin to a check-in 
comment) of branches and tags could require a new type of control artifact.


Any thoughts?

___
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] Repairing trunk/timeline after a shun

[Tony Papadimitriou]

In case it applies to you, if you haven't rebuilt the repo since the mistake 
shunning, I believe you can un-shun what was shunned, and it should all come 
back to the way it was.



On 5/14/2016 4:59 PM, John P. Rouillard wrote:
I had to recently shun some artifacts from a fossil repo (due to embedded 
security credentials). Now when I look at the fossil timeline that spans 
that shunning I no longer have a

single connected trunk.

So is there some way to reintegrate the trunk across the shun?



___
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] Colored output on console

[Tony Papadimitriou]

Possibly the best ‘color-blind proof’ method is reverse video.  Not the best 
looking in all cases, but certainly effective.

From: Scott Robison 
Sent: Sunday, April 24, 2016 7:39 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Colored output on console

On Apr 24, 2016 4:07 AM, "Marko Käning"  
wrote:
>
> Hi devs,
>
> it would be great if one could colorise Fossil’s output on the console!
>
> Quite a few times I missed an error or warning message which slipped in 
> between of many lines of the usual fossil output on the console.
>
> Red colouring of words like “warning” or “error” would be very helpful there.

I will just observe here that typically red text on a black background is 
really hard for me to see. If someone were to add such a thing, having it be 
opt in would be appreciated. Different people have different, of course. I hate 
color blindness.

>
> The poor man’s solution would at least be to use capital letters and some 
> sort of line head along the lines of
>
> > ERROR: blaa
> > WARNING: blubb
>
> Right now I can’t send an example of such a easily slipping through message, 
> but I can deliver if I come across one again.
>
> Greets,
> Marko
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] feature implemented or suggestion for stash

[Tony Papadimitriou]

I don’t know if this will be of any help, but I moved away from using stash 
altogether for pretty much the same reasons you mention, plus one very 
important one for me that I don’t like about the stash: the content of the 
stash only stays on the current PC while I wanted it to follow the repo file 
(e.g., backup).

I have found the use of private branches to work much better than stash, and no 
need for remembering extra stash specific commands.  For one thing they behave 
just like normal branches (except of course for the syncing – which you 
wouldn’t want and you can’t do with the stash anyway).  Once you’re ready to 
move the changes to a normal branch you simply merge (but without the 
–integrate option or else the purge won’t work correctly), and then purge the 
private branch.  You commit and all your intermediate private branch commits 
appear as a single folded commit.  Finally, once every so often you also 
obliterate any purges, and rebuild with the –compress-only option to get the 
repo size repo back down.
I still haven’t figured out if there is any functionality one can achieve with 
a stash that cannot be achieved (and possibly better/easier) with the above 
procedure.
From: fran 

In my case I use the stash to mark checkpoints like  in a editor and 
after several checkpoints and getting sure the thing is working fine I begin to 
flush the stash.

I'm satisfied with the size and intent of the stash feature but the 'list'  
seems pretty raw to me. The 'timeline' too but at least the timeline part is 
pretty good covered with the ui.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FOSSIL LS does not honor -R option

[Tony Papadimitriou]

I needed to see the file contents of a repo without opening it.

So, I tried the ls command with the –R repo option but I got an error message: 
current directory is not within an open checkout
But, the –R option is listed in the help for the ls command.

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] FOSSIL LS does not honor -R option

[Tony Papadimitriou]

OK, thanks.  Rereading the help it is now 'obvious' :)

-Original Message- 
From: Richard Hipp

Sent: Tuesday, January 26, 2016 5:39 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FOSSIL LS does not honor -R option

On 1/26/16, Tony Papadimitriou <to...@acm.org> wrote:

I needed to see the file contents of a repo without opening it.

So, I tried the ls command with the –R repo option but I got an error
message: current directory is not within an open checkout
But, the –R option is listed in the help for the ls command.



The -R options does not work unless you also include the -r option to
specify a specific version for which you want the directory listing.

--
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

[fossil-users] PURGE: Is this result buggy or expected?

[Tony Papadimitriou]

With all this talk about how to keep draft work out of the repo when done with 
it, I started playing with the various methods mentioned.

I noticed the following, and I would like to know if this expected behavior or 
some bug.
Regardless, it is disturbing to lose trunk (or other branch) commits without 
any warning, especially when that branch is not explicitly mentioned in the 
PURGE command.

Here’s the (Win7) commands to reproduce:
---
f new xxx.fossil
f o xxx.fossil
f com --force --branch base -m "Empty branch"
f up trunk
dir > a
f add a
f com -m "Added file"
dir > a
f com --branch other -m "Revised file"
dir > a
f com -m "Second revision of file"
f up trunk
f me other
f com -m "Merged other"
f ui
rem Next command gives error: cannot purge the current checkout
f pur other
rem Try again from 3rd independent branch
f up base
f pur other
f ui
---

At the two UI commands my output is this (before and after):


BEFORE PURGE OTHER


AFTER PURGE OTHER

If there were more commits in trunk after 5963, all of the them would be gone!  
I understand PURGE will kill all descendants of the given tag(s) but ‘trunk’ is 
not a sole descendant of ‘other’, as it also inherits ‘trunk’ so I would expect 
the propagation of the purge to stop right before the merge (i.e., after 
purging 0081).

The same procedure with --private, does not have this problem, and works as (I) 
expected.

I assume this is the reason ‘cannot purge the current checkout’ error is issued 
when trying the purge from within trunk.  But trying from a 3rd branch, no 
warning about destroying trunk.

Regardless, I would expect PURGE to only affect checkins 579b and 0081, and 
nothing more.  This is what happens if the OTHER branch is declared –private
(f com --branch other -m "Revised file" –private)

So, why this difference.  Is this for a reason or a bug?

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] FOSSIL SEARCH improvement suggestion

[Tony Papadimitriou]

I tried it, and no, it doesn't -- I'm talking about SEARCH from the 
command-line in case there is some misunderstanding.
(Let alone that the "Porter Stemmer" option changed my repo from 40MB to 
102MB!!!)


-Original Message- 
From: Richard Hipp

Sent: Tuesday, November 17, 2015 6:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FOSSIL SEARCH improvement suggestion

On 11/17/15, Tony Papadimitriou <to...@acm.org> wrote:


So, if you’re looking for the word ‘scroll’ it won’t match ‘scrolling’ and
vice versa.



"scroll" should match "scrolling" if you activate the "Porter Stemmer" 
option


--
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

[fossil-users] FOSSIL SEARCH improvement suggestion

[Tony Papadimitriou]

When using SEARCH you need to type the word exactly as it appears in the 
timeline.

I’m guessing it uses SQL’s LIKE to find the related matches.

So, if you’re looking for the word ‘scroll’ it won’t match ‘scrolling’ and vice 
versa.

One suggestion is to append ‘%’ to the search term to match any ending variant 
of the word.  It’s usually the ending of a word that differs.
It could also use % on either side to find the sought term inside any bigger 
word (perhaps with an option), perhaps ordering the exact matches before the 
rest.

A 2nd related suggestion (this only with the use of an option) is to use the 
SOUNDEX function to also catch sometimes misspelled words.

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] FOSSIL SEARCH improvement suggestion

[Tony Papadimitriou]

This worked (and I without the Porter Stemmer 'bloat'). Thanks.

-Original Message- 
From: Michael Keuter

Sent: Tuesday, November 17, 2015 6:10 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FOSSIL SEARCH improvement suggestion


Am 17.11.2015 um 17:03 schrieb Richard Hipp <d...@sqlite.org>:


On 11/17/15, Tony Papadimitriou <to...@acm.org> wrote:


So, if you’re looking for the word ‘scroll’ it won’t match ‘scrolling’ 
and

vice versa.


"scroll" should match "scrolling" if you activate the "Porter Stemmer" 
option


Or 'scroll*' :-).

Michael

http://www.mksolutions.info




___
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] Unexpected merge conflict

[Tony Papadimitriou]

Sorry for the confusion.
By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m doing the 
merge.
And, I’m merging the “check-in from the ... [other] branch”  I mean the 
check-in which is part of the other part.

I think I’m beginning to understand what’s going on.  If I do a full merge (no 
cherry pick) there are no conflicts.
So, it seems the fact that the SRF_OUT label was renamed in an earlier check-in 
that the one I’m cherry picking is confusing it.
What should have happened actually (what I expected with the cherry pick) is 
not exactly what I mentioned earlier.
The ‘puts’ change being part of the check-in I cherry picked should have merged 
in and the SRF_OUT rename (being from an older check-in) in the development 
branch should have stayed out.

This is a conflict if you look at this line of code as one piece (i.e., you 
either merge the whole line or none of it).
But, in reality the diff of the cherry picked check-in with its previous 
version has only the ‘puts’ change for that line, since the label was renamed 
much earlier.
And, that’s what I had expected would merge in the trunk.  Besides, since the 
rename hasn’t yet occurred in the trunk, I wouldn’t want that yet.

So, there is some problem there.  Now whether this is a bug, or just a merge 
algorithm limitation, I don’t know.
But, what is certainly confusing to figure out what may have happened is the 
common ancestor merge message line which shows content that never existed in 
the trunk version.  So, how can that be considered common?

(Then again, maybe I’m having a misconception of which the common ancestor is.)

Thanks.

From: Scott Robison 
Sent: Friday, November 13, 2015 5:53 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

On Nov 13, 2015 8:20 AM, "Tony Papadimitriou" <to...@acm.org> wrote:
>
> Here’s a merge conflict I thought should have been resolved automatically:
>  
> I have the trunk version from where the symbol RF_OUT is renamed to SRF_OUT 
> in the branch version.  It has never been renamed to SRF_OUT in the trunk 
> version (yet).
>  
> When trying to merge (--cherrypick, actually) from trunk the specific 
> check-in (either by giving the branch name or the actual check-in ID) from 
> the development branch that has the needed change, I got the following 
> unexpected merge conflict:

I am confused. You say merge "from trunk" & "from the development branch" in 
the same sentence. Is it possible you are going the wrong direction?

The common ancestor should not be the cherry picked commit, but there doesn't 
seem to be enough context here to positively identify which way is which or the 
common ancestor.

>  
> <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
> @?status  RF_OUT,#?MsgOn,#?MsgOff,fWriteZ
> === COMMON ANCESTOR content follows 
> @?status  SRF_OUT,#?MsgOn,#?MsgOff,fWriteZ
> === MERGED IN content follows ==
> @?status  SRF_OUT,#?MsgOn,#?MsgOff,puts
> >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>  
> As you can see, the common ancestor content shows the SRF_OUT label when that 
> label was named so only in the (under development) branch version.
>  
> Additional info that may help determine what went wrong:
> The SRF_OUT is renamed in the first node of the new branch several check-ins 
> before the cherry picked one.
> There have been two merged from the trunk (after the rename) but are 
> unrelated to this change and there were never any merge conflicts.
>  
> I expected the merged-in content to have completely replaced the local 
> version.
> Is there something I’ve done wrong that got fossil confused, is this a bug, 
> or simply a case of merge algorithm imperfection?  But, what confused it?  It 
> seems like a very simple change.
>  
> Thanks.
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Unexpected merge conflict

[Tony Papadimitriou]

Here’s a merge conflict I thought should have been resolved automatically:

I have the trunk version from where the symbol RF_OUT is renamed to SRF_OUT in 
the branch version.  It has never been renamed to SRF_OUT in the trunk version 
(yet).

When trying to merge (--cherrypick, actually) from trunk the specific check-in 
(either by giving the branch name or the actual check-in ID) from the 
development branch that has the needed change, I got the following unexpected 
merge conflict:

<<< BEGIN MERGE CONFLICT: local copy shown first <<<
@?status  RF_OUT,#?MsgOn,#?MsgOff,fWriteZ
=== COMMON ANCESTOR content follows 
@?status  SRF_OUT,#?MsgOn,#?MsgOff,fWriteZ
=== MERGED IN content follows ==
@?status  SRF_OUT,#?MsgOn,#?MsgOff,puts
>>> END MERGE CONFLICT >

As you can see, the common ancestor content shows the SRF_OUT label when that 
label was named so only in the (under development) branch version.

Additional info that may help determine what went wrong:
The SRF_OUT is renamed in the first node of the new branch several check-ins 
before the cherry picked one.
There have been two merged from the trunk (after the rename) but are unrelated 
to this change and there were never any merge conflicts.

I expected the merged-in content to have completely replaced the local version.
Is there something I’ve done wrong that got fossil confused, is this a bug, or 
simply a case of merge algorithm imperfection?  But, what confused it?  It 
seems like a very simple change.

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] Unexpected merge conflict

[Tony Papadimitriou]

Yes, sorry, I didn’t mention that.

‘puts’ replaced ‘fWriteZ’ in the last (cherry-picked) check-in – not in the 
same check-in as the label rename.  But, I think it’s irrelevant.

The important thing is that the common ancestor with regards to this line of 
code is the local version, since it hasn’t changed in the trunk, only in the 
branch.  So, I expected all (accumulated) changes in the merged-in 
cherry-picked check-in from the branch to appear in the trunk version.  Am I 
right?
From: Stephan Beal 
Sent: Friday, November 13, 2015 5:26 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

On Fri, Nov 13, 2015 at 4:20 PM, Tony Papadimitriou <to...@acm.org> wrote:

  <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<

  @?status  RF_OUT,#?MsgOn,#?MsgOff,fWriteZ
  === COMMON ANCESTOR content follows 
  @?status  SRF_OUT,#?MsgOn,#?MsgOff,fWriteZ
  === MERGED IN content follows ==
  @?status  SRF_OUT,#?MsgOn,#?MsgOff,puts
  >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  As you can see, the common ancestor content shows the SRF_OUT label when that 
label was named so only in the (under development) branch version.

  Additional info that may help determine what went wrong:
  The SRF_OUT is renamed in the first node of the new branch several check-ins 
before the cherry picked one.
  There have been two merged from the trunk (after the rename) but are 
unrelated to this change and there were never any merge conflicts.

are you sure they were unrelated: you didn't mention the "puts" vs "fWriteZ" 
change in your description. Could it that that is the source of the conflict?


-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do." -- Bigby Wolf



___
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] fossil v1.34 unexpected CLEAN command changes from v1.33

[Tony Papadimitriou]

Thanks.

BTW, the help for clean shows this (which is a bit misleading):

--no-prompt  This option disables prompting the user for input and 
assumes an answer of 'No' for every question.


But, if prompting is disabled by default, how does that disable it further?

-Original Message- 
From: Richard Hipp

Sent: Tuesday, November 03, 2015 3:09 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] fossil v1.34 unexpected CLEAN command 
changesfrom v1.33


On 11/2/15, to...@acm.org  wrote:
I built the latest version and (unfortunately, for me) CLEAN no longer 
asks

for confirmation.

Is this something I can have behave the way it was in v1.33 via some
setting?  (I often do a clean but may want to skip some file, so I like to
be asked.)


I just added the "fossil clean -i" or "--prompt" option that forced a
prompt for each file.  Still in a branch.



If not possible anymore, is there at least some way to see which files get
cleaned (other than running with –n option in advance which would require
running the clean command twice all the time – and remembering about it) 
so

I can undo the specific one I want to keep?

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] Questions about wiki linking to non-branch artifact IDs/images

[Tony Papadimitriou]

Thanks, that worked great!

As it turns out a quick way to do this without much typing is to go to the 
attachment details and simply copy the Image button link.
Then, put this inside a  tag
(where xxx is the copied link, but delete everything before the /raw -- 
usually, localhost:8080)

-Original Message- 
From: Andy Bradford 
Sent: Thursday, October 22, 2015 7:36 AM 
To: Tony Papadimitriou 
Cc: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Questions about wiki linking to non-branch artifact 
IDs/images 

Thus said "Tony Papadimitriou" on Mon, 19 Oct 2015 16:24:49 +0300:

> My question is how  can I add this image to the repo  in a way that it
> is not part of any branch or ticket (e.g., attachment to a ticket)?

Attach it to the  Wiki page. Then add an img tag to  the Wiki page using
the /raw command:



You can get the  UUID of the artifact by clicking on  the details of the
attachment.

Here's documentation on the /raw command:

http://www.fossil-scm.org/index.html/help?cmd=/raw

Fossil proper  actually uses  Embedded Documentation  via /doc  to serve
images  within  its   pages.  For  example,  all  the   images  in  this
documentation are in the www repository directory, but served via /doc:

http://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

Andy
-- 
TAI64 timestamp: 4000562867dc
___
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] Questions about wiki linking to non-branch artifact IDs/images

[Tony Papadimitriou]

Similar problem here.  I thought I would get the image to display as part of 
the Wiki page and not as an attachment link.


Is there a way to make the attached image display directly when opening the 
wiki page?  (I don't mind the attachment link too much -- if there is no 
other way -- but the ideal would be to have the image display directly.)


-Original Message- 
From: The Tick

Sent: Wednesday, October 21, 2015 3:25 AM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Questions about wiki linking to non-branch 
artifact IDs/images


On 10/19/2015 9:36 AM, Richard Hipp wrote:

On 10/19/15, Tony Papadimitriou <to...@acm.org> wrote:


My question is how can I add this image to the repo in a way that it is 
not

part of any branch or ticket (e.g., attachment to a ticket)?
I only need it for the purpose of being shown in the wiki page but I do 
not

want it to be part of any checkout or ticket.



Add the image as an attachment to the wiki page.  Then edit the wiki
page to reference the attachment.  (I remember adding that capability
way back when I was first designing Fossil, but I haven't actually
used it so I don't remember the exact syntax.)



This is similar to what I want to do so I gave it a try--I added an
image to a wiki page as an attachment. It's not what I want. It adds
text to the bottom of the page that says "Attachments".

How can I remove the attachment now?

Perhaps if I knew what "artifacts" or "artifact ids" were, I could
figure it out. Are there any docs on all this terminology?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Questions about wiki linking to non-branch artifact IDs/images

[Tony Papadimitriou]

I’m trying to add an image to a wiki page.  I want the image to be stored 
inside the same fossil repo (i.e., not external link).

I read about all the possible ways one can create links with the [...] syntax.  
For example, I can either use the artifact ID, or an image name.

My question is how can I add this image to the repo in a way that it is not 
part of any branch or ticket (e.g., attachment to a ticket)?
I only need it for the purpose of being shown in the wiki page but I do not 
want it to be part of any checkout or ticket.

Thanks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] REVERT vs. UPDATE clarification?

[Tony Papadimitriou]

When restoring a previous version of a single file, is there any practical 
difference between the following two actions:

fossil up version file
fossil rev -r version file

I have been using the UPDATE method up to now.  But, I ran into the other 
possibility in the docs and I wonder when each should be used, or do they 
always have exactly the same effect?

Thanks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion for command-line timeline display

[Tony Papadimitriou]

Hello,

Not too long ago SQLite3 shell got a colored startup message about using 
“transient in-memory database”.

I was wondering if the same idea could be used to highlight the *CURRENT* entry 
in the timeline (with some soft color – a shade of blue or green would be nice).
This is because in a timeline with a lot of sequential *MERGE* entries, finding 
*CURRENT* becomes a little ‘difficult’.  Why not have some color make it very 
obvious?

(BTW, in the way things are, I think the *CURRENT* message would stand out a 
little better if it came first, i.e., before the *MERGE* message.)

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] Suggestion for command-line timeline display

[Tony Papadimitriou]

I didn't actually try it but from what it looks like, yes, almost, BUT

1. highlight the whole entry, not just the word *CURRENT*, and
2. it should also work without ANSI escape sequence under Windows console.

Also, the best 'color' would probably be just bold print to make it stand 
out from the rest.


-Original Message- 
From: Andy Bradford 
Sent: Thursday, October 01, 2015 5:20 PM 
To: Tony Papadimitriou 
Cc: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Suggestion for command-line timeline display 


Thus said "Tony Papadimitriou" on Thu, 01 Oct 2015 15:29:05 +0300:


I  was wondering  if the  same  idea could  be used  to highlight  the
*CURRENT* entry  in the  timeline (with some  soft color---a  shade of
blue or green would be nice).


You mean like this:

fossil time | sed -e 's/\*CURRENT\*/^[[0;32m&^[[0;m/'

Where ^[ is an escape character.

Andy
--
TAI64 timestamp: 4000560d414a

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] MERGE problem

[Tony Papadimitriou]

I’m in some branch and doing a MERGE from trunk.

Everything OK except for some newly added files on trunk that were not in the 
current branch, but a merge was expected to deal with them also.
But, they do not ‘copy over’.  The result is the project is incomplete as the 
updated files depend (#include) the missing ones.

I can do a manual UPDATE to bring each file in the working branch from trunk 
‘by hand’ but shouldn’t a MERGE take care of that also?

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] MERGE problem

[Tony Papadimitriou]

> I can do a manual UPDATE to bring each file in the working branch from trunk 
> ‘by hand’ but shouldn’t a MERGE take care of that also?

Strike that out.  I talked without testing it first.  This does not work, 
either.  The file(s) reported as ‘not found’

From: Tony Papadimitriou 
Sent: Thursday, September 24, 2015 5:59 PM
To: Fossil SCM user's discussion 
Subject: [fossil-users] MERGE problem

I’m in some branch and doing a MERGE from trunk.

Everything OK except for some newly added files on trunk that were not in the 
current branch, but a merge was expected to deal with them also.
But, they do not ‘copy over’.  The result is the project is incomplete as the 
updated files depend (#include) the missing ones.

I can do a manual UPDATE to bring each file in the working branch from trunk 
‘by hand’ but shouldn’t a MERGE take care of that also?

Thanks.



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Feature request: FOSSIL ALL CLOSE

[Tony Papadimitriou]

Is it possible to have an ‘FOSSIL ALL CLOSE’ command?

I usually have several unrelated fossils open at once.  And because of working 
on the same ones from work and home (and sometimes notebook), and how I 
transfer backups back and forth at the end of the day, I *need* to close all 
open fossils, but sometimes I forget which ones I had opened, so I have to go 
to each directory and check with something like ‘FOSSIL CHA’ to get the message 
“current directory is not within an open checkout” if the fossil is already 
closed, or else do a “FOSSIL CLOSE”.

I thought it would much simpler if I could just issue a “FOSSIL ALL CLOSE” 
command.

Thanks.

P.S. I know many people don’t bother closing the fossil at all.  However, I 
find the alternative of pushing to a USB drive not convenient when the same 
fossil needs to also be pushed on a local server not reachable from the 
Internet.  So, since the push settings can either point to the USB or the 
server, it’s much simpler to just backup the whole fossil file.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Tony Papadimitriou]

When doing:

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.

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] mv --hard bug!

[Tony Papadimitriou]

Here’s the actual transcript of what I tried today, without success (on a Win7 
machine):


C:\progs\lua\sof mv 30689195_othershack.lua 30689195_others_hack.lua --hard
RENAME so/30689195_othershack.lua so/30689195_others_hack.lua
cannot open C:/progs/lua/so/so/30689195_othershack.lua for reading

C:\progs\lua\sof cha
MISSING30689195_others_hack.lua

C:\progs\lua\sodir 30689195_othershack.lua
Volume in drive C is Win7
Volume Serial Number is -

Directory of C:\progs\lua\so

08/06/2015  02:32 μμ   121 30689195_othershack.lua


The repo root is one directory above this one.
As you can see the ...so/so... in the path shows that the mv on the disk was 
attempted with a full relative path (from repo root) instead of the path 
relative to where I was at the moment (inside so subdirectory).

My fossil is:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
UNICODE_COMMAND_LINE

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Stash DIFF

[Tony Papadimitriou]

Hello,

Is there a way to see a ‘diff’ between two stashed ids, rather than stash to 
disk?

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Bug? FOSSIL MV does not work as expected (Win7 machine)

[Tony Papadimitriou]

This is on a Win7 machine (if it matters).  A simple way to reproduce (f = 
fossil):

f new xxx.fossil
f o xxx.fossil
mkdir a\a
dir  a\a\xxx
f add a
f com -m Initial
f mv a\a b
f close

Based on help screen, and usual behavior of mv, I would expect subdirectory a\a 
to be now known as b, and of course all files below to move accordingly.  But 
nothing happens.  If I move each file separately, it works.

This is what the help screen shows:

Usage: f mv|rename OLDNAME NEWNAME
   or: f mv|rename OLDNAME... DIR

Move or rename one or more files or directories within the repository tree.
You can either rename a file or directory or move it to another subdirectory.
___
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] Repo with many initial commits + more wish list

[Tony Papadimitriou]

It has its pros and cons.  Most important ones I see:

+ Common files will only be stored once (having the same SHA) so overall 
size of repos is smaller than the total of separate repos, one for each 
project.
- If common files change, you need to merge changes to each project 
separately, making it a bit tedious, especially as the number of projects 
grows.
- Keeping too many (large) projects may make the single repo file extremely 
large and difficult to transfer or to backup.
- You cannot split out a project at a later time (wish list).  So, you're 
stuck with this arrangement for good.


Multi-project repos is a very useful use case.  All my repos are such.  This 
is mostly a necessity by the fact all these projects share code in one way 
or another, and there is no convenient alternative for this.


Just a few related ideas to add to the wish list:

* As hinted above, it would be nice if FOSSIL could create a new repo from 
another repo's existing branch (or branch set).  So, if I want to separate a 
project to a new repo (either because of size, or simple because I want to 
make just one project a separate repo for publishing), I could somehow 
create a new repo by extracting a branch set from a previous repo.


* It would be nice if FOSSIL allowed for a special kind of branch that would 
be common to all other branches.  So, that all common code (libraries, etc.) 
could be placed in that one branch and then this branch would be checked out 
with any other branch checkout, and updated the same way.  So, making a 
change to files belonging in that common branch would ultimately affect all 
projects without any further action.Opening a branch would open the 
actual branch plus the common branch as the two were one.  Obviously, it 
cannot be allowed that files (paths) belonging in common branch are also 
part of the normal branch, or the other way around.


* People wanting to come to FOSSIL from other systems (with the exception of 
git for which there is an import feature) have to wait for a new project if 
the want to keep the full history of changes, or go through a very tedious 
and time consuming process of manually generating the repo to look as if it 
was used from the beginning of the project.  (To get an accurate result, you 
need to fiddle with the system clock to pretend you're committing at an 
older date/time.  Although fossil's concept is to have an immutable repo 
(and I completely agree with that), so there can't be a way to add history 
after the repo has been used a bit, there should be some method to create a 
fresh repo (or timeline) from existing files in a chronological order 
(either according to the file's date/time stamp, or by some explicit 
date/time option), and the result should be as if the repo (or timeline) was 
actually created over time.  This action should only be allowed once on a 
fresh empty repo or initial commit.  For example, the user places all 
historic file sets (commits-to-be) in distinct subdirectories, and then 
FOSSIL via a special command (again, to be allowed only once per initial 
empty commit), goes over each subdirectory recursively, putting the contents 
in an automatically generated 'commit' (and a relevant comment like 'auto 
commit') using as date the most recent file's date of the respective 
subdirectory.  After the first automatic commit is processed, the rest of 
the history should be treated the same way as manual commits, as if the user 
had done an 'addremove .' followed by 'commit'.


Tony P.

-Original Message- 
From: Vikrant Chaudhary

Sent: Tuesday, January 27, 2015 2:37 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Repo with many initial commits

I personally think that fossil open --empty is a pretty good
strategy to keep multiple projects in the same repository.

Cheers.
- Vikrant

___
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] Newbie question

[Tony Papadimitriou]

The way I solve this problem is to keep a repo of all projects that share 
the same libraries together.  This creates some other minor problems (that 
were recently made less of a problem with the -p option enhancement of the 
TIMELINE command.)  But, I think this is the only reasonable way.


There is also another possibility.  Under Windows, you can use the MKLINK 
command to create a directory junction under your project (each project). 
This way you can keep the tree structure you have, keep a single copy of 
your libraries, but make it appear as if each project has its own copy. 
FOSSIL will treat this as a normal directory, meaning that if you open the 
repo somewhere else (where the junction does not exist), you will get a copy 
of you library.


One potential problem with this approach is that, even though there is a 
single copy of the library, each project thinks it has a private copy.  So, 
making library changes for the sake of one project have to be propagates to 
all other repos using the same library in their projects.


Tony
-Original Message- 
From: jose isaias cabrera

Sent: Friday, November 07, 2014 12:32 AM
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] Newbie question


Greetings!

First of all, I want to thank you whomever was the creator of this wonderful
utility.  Props to you.

I have a setup on my Windows PC where I have many sources of various
languages.  That will be another question later, but today, I have a
project, which I created a repo for it, but I have libraries somewhere else.
Imagine this scenario:

Project lives on: c:\sources\d\MyProject\MyProject.d
Libraries used by this project live on: c:\D\import
 
\my\lib\aaa.d
 
\my\lib\bbb.d
 
\my\lib\ccc.d
 
\my\lib\ddd.d
 
\my\lib\eee.d
 
\my\lib\fff.d
 
\other0\lib\aaa.d
 
\other1\lib\aaa.d

The problem is that when I make changes to the to the
c:\sources\d\MyProject\MyProject.d everything is fine I get the new version
etc.  But, when I make changes in c:\D\Import, the changes are not being
checked in.  I know I can open another repo and keep track of them like
that, but is there another way where I can point to another directory and
still use the repo for c:\sources\d\MyProject\MyProject.d?  I hope I was
clear enough.  Thanks.

josé

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FOSSIL ALL

[Tony Papadimitriou]

I have several repos open at the same time, not always the same ones.  Before I 
swap computers (home = work) I would like to close all open repos on one 
site, and take a backup to take to the other site.

But there is no easy way to find out which repos are currently open – so, I 
must explicitly visit each subdirectory, run a command like FOSSIL CHANGES to 
get a message whether the repo is open or not.  Perhaps FOSSIL ALL LIST (or LS) 
could also show the status of the related repo.  Something like:

 FOSSIL ALL LIST
/somepath/a.fossil
/otherpath/b.fossil (OPEN)
/who/knows/where/path/c.fossil
/temp/d.fossil
/whatever/e.fossil (OPEN)

And, how about a command to close all open repos at once, e.g., at the end of 
the day?  FOSSIL ALL CLOSE should of course stop at the first repo that has, 
say uncommitted changes, the same way a FOSSIL CLOSE does, unless a –FORCE 
option is used.

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] FOSSIL ALL

[Tony Papadimitriou]

Actually, FOSSIL ALL LIST shows all repos, including the closed ones.  If it 
only showed the open ones, half of my problem would be solved (although a new 
one would be created – how to see all repos installed on a given machine).

Regarding the rest of your comments please see my response to Dr Hipp.

From: Stephan Beal 


That won't (or shouldn't) work because once a repo is closed it will (or 
should) no longer show up in the 'all' list.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL ALL

[Tony Papadimitriou]

OK, maybe I have a misunderstanding of the need for close.  What is it used 
for?  The claim by Stephan Beal that he hasn’t closed a repo more than 5 times 
over many years makes me wonder why is there even a CLOSE command?

In my case, there is no server used, because this is private work that I cannot 
trust to be placed on any public server since I do not want anyone to have 
access to it (and by anyone I include the owner of the public server).  I have 
thought about setting up a server on one of the two machines (home or office) 
but that would require one of these computers to be always on, which again I 
would rather not have.  So, in my case, my only alternative is to move the 
fossil file from computer to computer – so that the ‘master’ relocates all the 
time between two points.  And, proper procedure for most applications would be 
to close a file, transfer it, and then re-open it.  But, maybe fossil is more 
lenient... I don’t know.

So, are you saying, that if I keep both repo versions (work and home) open all 
the time, and simply copy over (from the backup) the related fossil files, 
there won’t be any corruption on either site?  And, I suppose instead of open 
(at the start of the day), I should be doing what exactly?  FOSSIL REV to 
update the current checkout from the just updated FOSSIL file which would 
appear like a revert on the other side?  Or, an UPDATE?  And, what if I’m on 
different branches?  Is this guaranteed to work correctly without creating any 
unpleasant side effects, from simple forks, etc., to the most serious of which 
would be a corruption of the repo and loss of work (and not only one day’s)?

OK, maybe I do not need the functionality I asked for but can someone explain 
what would be the equivalent work flow between two different machines where 
there is no common server, and the FOSSIL file is at any moment replaced with a 
new file (from the other machine?)  Currently, my process is this:

LOOP:
FOSSIL OPEN 
... code changes ...
FOSSIL COMMIT
FOSSIL CLOSE

transfer repo file to other machine, and copy it over the previous version
goto LOOP

From: Richard Hipp 
Sent: Monday, October 27, 2014 1:11 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FOSSIL ALL



On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote:

  I have several repos open at the same time, not always the same ones.  Before 
I swap computers (home = work) I would like to close all open repos on one 
site, and take a backup to take to the other site.


Close them?  Why do you want to do that?

It seems to me that all you really need to do is ensure that all changes have 
been committed, which can be accomplished using fossil all changes.


Presumably, all of your repos have a default sync partner - probably a master 
repository on a server someplace.  (At least, that is the way I work things.  I 
have 35 projects currently going on my desktop, all of which are mirrored on 
one of two servers I control in the cloud.)  In that case, all you need to do 
before leaving work is fossil all changes to look for uncommitted changes.  
Then when you get to home, just do fossil al sync to pull all the changes 
from work down to your home machine.  Nothing needs to be closed.  When heading 
back to work, just do fossil all changes on your home machine to make sure 
you have committed everything, then fossil all sync when you get back to the 
office.


The scenario above is exactly why I invented fossil all.  :-)

-- 
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] FOSSIL ALL

[Tony Papadimitriou]

I guess the same scenario would be valid if one used a server but had private 
branches.  My understanding is that private branches do not sync so the only 
way to move to another location is to move the whole fossil file.  Correct?

From: Tony Papadimitriou 
Sent: Monday, October 27, 2014 1:48 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FOSSIL ALL

OK, maybe I have a misunderstanding of the need for close.  What is it used 
for?  The claim by Stephan Beal that he hasn’t closed a repo more than 5 times 
over many years makes me wonder why is there even a CLOSE command?

In my case, there is no server used, because this is private work that I cannot 
trust to be placed on any public server since I do not want anyone to have 
access to it (and by anyone I include the owner of the public server).  I have 
thought about setting up a server on one of the two machines (home or office) 
but that would require one of these computers to be always on, which again I 
would rather not have.  So, in my case, my only alternative is to move the 
fossil file from computer to computer – so that the ‘master’ relocates all the 
time between two points.  And, proper procedure for most applications would be 
to close a file, transfer it, and then re-open it.  But, maybe fossil is more 
lenient... I don’t know.

So, are you saying, that if I keep both repo versions (work and home) open all 
the time, and simply copy over (from the backup) the related fossil files, 
there won’t be any corruption on either site?  And, I suppose instead of open 
(at the start of the day), I should be doing what exactly?  FOSSIL REV to 
update the current checkout from the just updated FOSSIL file which would 
appear like a revert on the other side?  Or, an UPDATE?  And, what if I’m on 
different branches?  Is this guaranteed to work correctly without creating any 
unpleasant side effects, from simple forks, etc., to the most serious of which 
would be a corruption of the repo and loss of work (and not only one day’s)?

OK, maybe I do not need the functionality I asked for but can someone explain 
what would be the equivalent work flow between two different machines where 
there is no common server, and the FOSSIL file is at any moment replaced with a 
new file (from the other machine?)  Currently, my process is this:

LOOP:
FOSSIL OPEN 
... code changes ...
FOSSIL COMMIT
FOSSIL CLOSE

transfer repo file to other machine, and copy it over the previous version
goto LOOP

From: Richard Hipp 
Sent: Monday, October 27, 2014 1:11 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FOSSIL ALL



On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org wrote:

  I have several repos open at the same time, not always the same ones.  Before 
I swap computers (home = work) I would like to close all open repos on one 
site, and take a backup to take to the other site.


Close them?  Why do you want to do that?

It seems to me that all you really need to do is ensure that all changes have 
been committed, which can be accomplished using fossil all changes.


Presumably, all of your repos have a default sync partner - probably a master 
repository on a server someplace.  (At least, that is the way I work things.  I 
have 35 projects currently going on my desktop, all of which are mirrored on 
one of two servers I control in the cloud.)  In that case, all you need to do 
before leaving work is fossil all changes to look for uncommitted changes.  
Then when you get to home, just do fossil al sync to pull all the changes 
from work down to your home machine.  Nothing needs to be closed.  When heading 
back to work, just do fossil all changes on your home machine to make sure 
you have committed everything, then fossil all sync when you get back to the 
office.


The scenario above is exactly why I invented fossil all.  :-)

-- 
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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FINFO suggestion

[Tony Papadimitriou]

FINFO (Usage: fossil finfo ?OPTIONS? FILENAME) is one of the most useful 
features of fossil as it accepts a filename and provides its history of changes 
(unfortunately, it does not follow possible file renames, but that’s another 
issue).

What I would like is to have the possibility to also specify a directory 
instead of filename, and get the history of all related files (i.e., files 
inside that subdirectory).
It is often the case I need to see the historic changes of a whole 
subdirectory, and if there are several files, I have to do it one at a time, 
which is a bit frustrating.

Would that be too much programming effort to add?  I.e., check if ‘filename’ is 
a directory and in that case return FINFO for all associated files.___
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] auto-sync before merge?

[Tony Papadimitriou]

As a general observation, I would say that options is the ONLY option to 
allow multiple mentalities to co-exist!  And, I just proved it! :)


-Original Message- 
From: Ramon Ribó

Sent: Friday, October 10, 2014 11:32 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] auto-sync before merge?

Please, do not add a new option.

I read in an interesting article about software development that every
new option in a program is a failure of the designer, who has been
unable to take a decision. Every new option represents a more
complicated manual, a sense of complexity of the product and a new
opportunity to have more bugs in the less used branch of the option.

I do not completely agree with this idea, as sometimes options are
useful to give opportunity to use the same program with different
workflows. However, I consider more of a success of a program every
option avoided than every option added.

RR


2014-10-10 10:08 GMT+02:00 Stephan Beal sgb...@googlemail.com:

On Fri, Oct 10, 2014 at 10:01 AM, Ramon Ribó ram...@compassis.com wrote:


If autosync is activated, of course it should do it. In fact, I see it
as an error not doing it. Does not 'autosync' means: do all the pushes
and pulls necessary to keep local repository always syncronized with
remote repository?



Historically yes, but not in the context of a merge. Merging has, in terms
of workflow, always assumed offline mode, performing no explicit 
syncing.

Whether or not the historical meaning of autosync should be expanded to
cover other commands is debatable, and i'd argue for a new option either
specific to merge or generically for use with commands which optionally 
want

to pull automatically but not push.

--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby 
Wolf


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion for win/Makefile.msc

[Tony Papadimitriou]

Chances are when you use FOSSIL_BUILD_SSL you also want to enable SSL.
So, to avoid having to give both FOSSIL_BUILD_SSL and FOSSIL_ENABLE_SSL on the
make command line, I propose something like this change in the win/Makefile.msc:

--- OLD ---
# Uncomment to enable SSL support
# FOSSIL_ENABLE_SSL = 1

# Uncomment to build SSL libraries
# FOSSIL_BUILD_SSL = 1

--- NEW ---

# Uncomment to build SSL libraries
# FOSSIL_BUILD_SSL = 1

# Uncomment to enable SSL support
# FOSSIL_ENABLE_SSL = 1

!ifdef FOSSIL_BUILD_SSL
!ifndef FOSSIL_ENABLE_SSL
FOSSIL_ENABLE_SSL = 1
!endif
!endif

--- END --___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to use the ticket subsystem?

[Tony Papadimitriou]

When editing a ticket, the 'Subsystem' drop-down list is blank.

Question: How do I enter new values, or how do I define the possible values 
from which to choose?


Since I keep multiple applications in a single repository (because they all 
depend on common library code), I would like to use this to know to which 
application the tickets refers without taking space from the actual ticket 
description.


TIA 


___
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] gdiff/opendiff on os x: suppress unchanged files?

[Tony Papadimitriou]

MessageWell, it may not seem like a problem if you compare a single file that 
you know has no differences, but imagine you’re checking a specific directory 
with hundreds of files, only one or two of which have changed.  Fossil will 
invoke WinDiff and have you look at every single file in that directory, 
instead of the one or two that actually have changed.  So, it IS kind of a 
problem, unless you avoid using WinDiff and use –tk option.

From: dave 
Sent: Thursday, September 25, 2014 12:07 AM
To: 'Fossil SCM user's discussion' 
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files?

Oh, OK.  Well, if I do, say
  C:\Experiments\libfossilfossil gdiff configure
in my environment, I do indeed get a WinDiff on that file showing no changes, 
but isnt' that what I asked it to do, rather than not pop up WinDiff at all and 
make me think something is wrong?

Oh, well, I guess I don't understand the particualr use-case, and probably I'm 
just adding noise to the conversation at this point, so I'll duck out.  At 
least in the scenarios I described below, it seems to be working right to my 
sensibilities in at least version 1.29.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Minor CAT command bug and LS command enhancement request

[Tony Papadimitriou]

Hi,

First, a minor bug in the CAT command (on Win machine): Using a backslash in 
the path does not find the file, while using a forward slash finds it.


Second, would it be possible to add the -R repo_file option to the LS 
command?  It'd be nice to get the list of files without opening the repo.


Thanks. 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FOSSIL DIFF --TK improvement

[Tony Papadimitriou]

Hello,
The --TK option of the DIFF command brings up a window with the side by side 
comparison of the files but (on Win7 at least), this window is not in the 
foreground, and it also always moves location (from invocation to invocation) 
so that sometimes part of it even falls outside the screen.  Both of these are 
minor nuisances since one can correct, but they require extra typing, which 
shouldn’t be necessary, IMO.
So, I would like to see this improvement, if possible:  Once launched, the 
window to come in front of other windows, and its position to be always 
centered.
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] Inconsistency with DIFF/GDIFF and --brief option

[Tony Papadimitriou]

I think that's the way to go. Revert to diff behavior. 

Ron W ronw.m...@gmail.com wrote:

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] diff with --from --to

[Tony Papadimitriou]

Just an idea:
f g somefile --to trunk
gives this error: “must use --from if --to is present”, while:
f g somefile --from trunk
f g somefile --from current --to trunk  (same as before but opposite direction)
both work just fine.  So, why not make the “--from current” the default when no 
--from option is found, instead of giving an error?
Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to compare set of files between versions?

[Tony Papadimitriou]

Hi all,
Here’s my predicament:
While investigating a bug, I want to get the differences between certain files 
between two versions, but not all files that may have changed.
I can use “F(OSSIL) G(DIFF) filename --FROM version” to compare a single file.
I can use “F(OSSIL) G(DIFF) --FROM version” to compare all files that changed.  
Hundreds of files most of which are irrelevant to the problem.
So, how do I compare only a set (e.g., a single subdirectory)?  When the 
versions are too far apart, hundreds of files may have changed in between.  
But, since I know the problem I’m looking for lies in a specific subset, I want 
to look at only those files.
I tried “F(OSSIL) G(DIFF) subdir/*.mod --FROM version” which gives a 
doesn’t-exist error.  I tried any variation I could think of.  Although I’m 
interested to see differences for a specific set of files matching a mask in a 
specific subdirectory, I even tried to compare the whole subdirectory by 
omitting the mask, but still it gives the same error.
Any way to do this other than trying to manually type every single file to 
check?  Or, is it ONE or ALL?
Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to avoid 'touching' the fossil repo for read-only operation?

[Tony Papadimitriou]

Hi,

Every time I open a fossil repo, even if I simply open it to just get a copy 
of the files in some directory, I end up with a 'touched' repo file, as if 
some 'write' operation has occurred in the database.  And a binary compare 
of before and after shows that some bytes actually change.  However, if 
there are no commits, or any of the other operation that would normally 
write into the SQLite database, why is the database file updated at all?  Is 
this 'writing' a necessity for fossil's normal operation, or is it something 
that could be avoided by improving fossil?


Why is this a nuisance?  Because software that automatically backs up files 
based on their having been touched since last time will backup those files 
even when they haven't changed at all (from a logical point of view, even if 
something is actually written in them, it seems to be irrelevant as they 
will behave the same as the version before the 'write' occurred.)


Thanks. 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users