Re: [fossil-users] anomaly using [g]diff

2014-05-13 Thread Jan Nijtmans
2014-05-13 3:34 GMT+02:00 Will Parsons varro@nodomain.invalid:
 repository:   /home/william/FOSSIL/recepsum.fossil
 local-root:   /home/william/mlc/recepsum-database/
 config-db:/home/william/.fossil

Your .fossil file contains information on which files are locally
changed. The vfile table rememberd rid's for each file which
is in the current checkout. Those rid's are searched in
the blob table in your recepsum.fossil database.

My guess is that you re-cloned recepsum.fossil and wrote
it over the original recepsum.fossil file. This can result in
chaned rid's, so the rid's in your .fossil file doesn't match
your recepsum.fossil any more. That could result in
exactly the symptoms you are seeing.

You can fix that with:
 fossil checkout f51f0cfb9eed704a0e92364e1e6ea5d6d97c2365 --keep

(The uuid is from the checkout line for your fossil stat)

Regards,
 Jan Nijtmans
___
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] committing wiki pages changes format parser

2014-05-13 Thread Stephan Beal
On Tue, May 13, 2014 at 12:12 AM, Chad Perrin c...@apotheon.net wrote:

 When I use the fossil wiki command to work with wiki pages at the
 shell, edit files and check them back in, what was once treated as a
 markdown formatted wiki page gets coerced back to being a wiki markup
 formatted wiki page.  How do I stop this from happening?


Doh - you can't currently. The shell mode export/import was added _long_
before other formats were supported, and it's not aware of them. i've added
that to the TODO list.


 While I'm at it . . . how do I stop changes saved from the web interface
 from inserting a bunch of MS Windows style ^M CRLF character garbage
 at the end of every line when I check out a wiki file locally for
 editing in a text editor?


That's new to me - i don't recall ever having seen that.

-- 
- 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] Markdown rules for Fossil Wiki

2014-05-13 Thread Gerald Gutierrez
I understand from the wiki formatting rules page that links can be created
via [mylink], but this doesn't work if I use markdown. I can use the
[thename](target_link) markdown style, but that is a generic link and I
seem to have to specify the full link and not just the wiki page name.

Is there a proper way to specify a wiki-internal link using markdown or
must I use the HTML-style wiki formatting rules?

Gerald.
___
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] committing wiki pages changes format parser

2014-05-13 Thread Chad Perrin
On Tue, May 13, 2014 at 09:55:10AM +0200, Stephan Beal wrote:
 On Tue, May 13, 2014 at 12:12 AM, Chad Perrin c...@apotheon.net wrote:
 
  When I use the fossil wiki command to work with wiki pages at the
  shell, edit files and check them back in, what was once treated as a
  markdown formatted wiki page gets coerced back to being a wiki markup
  formatted wiki page.  How do I stop this from happening?
 
 Doh - you can't currently. The shell mode export/import was added _long_
 before other formats were supported, and it's not aware of them. i've added
 that to the TODO list.

Thanks.  I look forward to that going away.


 
  While I'm at it . . . how do I stop changes saved from the web interface
  from inserting a bunch of MS Windows style ^M CRLF character garbage
  at the end of every line when I check out a wiki file locally for
  editing in a text editor?
 
 
 That's new to me - i don't recall ever having seen that.

Is there any other information I could provide that might help narrow
down the source of the problem?  I'm currently at kind of a loss.

The local install of Fossil is 1.28 built from ports on FreeBSD.  The
remote install is 1.26 built from downloaded sources on a Linux-based
webhosting platform (though I expect to move that to a FreeBSD VPS,
with Fossil installed from ports and thus more up to date, soon).

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] committing wiki pages changes format parser

2014-05-13 Thread Martin Gagnon
On Tue, May 13, 2014 at 01:27:17PM -0600, Chad Perrin wrote:
 On Tue, May 13, 2014 at 09:55:10AM +0200, Stephan Beal wrote:
  On Tue, May 13, 2014 at 12:12 AM, Chad Perrin c...@apotheon.net wrote:
  
   When I use the fossil wiki command to work with wiki pages at the
   shell, edit files and check them back in, what was once treated as a
   markdown formatted wiki page gets coerced back to being a wiki markup
   formatted wiki page.  How do I stop this from happening?
  
  Doh - you can't currently. The shell mode export/import was added _long_
  before other formats were supported, and it's not aware of them. i've added
  that to the TODO list.
 
 Thanks.  I look forward to that going away.
 
 
  
   While I'm at it . . . how do I stop changes saved from the web interface
   from inserting a bunch of MS Windows style ^M CRLF character garbage
   at the end of every line when I check out a wiki file locally for
   editing in a text editor?
  
  
  That's new to me - i don't recall ever having seen that.
 
 Is there any other information I could provide that might help narrow
 down the source of the problem?  I'm currently at kind of a loss.
 
 The local install of Fossil is 1.28 built from ports on FreeBSD.  The
 remote install is 1.26 built from downloaded sources on a Linux-based
 webhosting platform (though I expect to move that to a FreeBSD VPS,
 with Fossil installed from ports and thus more up to date, soon).

Hi, 

I confirm, I have same result: (on linux x64)

  $ fossil ver
  This is fossil version 1.29 [379309b6da] 2014-04-30 07:43:47 UTC

  $ fossil wiki export test wiki  test.wiki

  $ file test.wiki
  test.wiki HTML document, ASCII text, with CRLF, LF line terminators

It's even not a real CRLF (DOS) file but a mix between CRLF an LF...


Moreover, same thing happens with fossil conf export.


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


Re: [fossil-users] anomaly using [g]diff

2014-05-13 Thread Will Parsons
Jan Nijtmans wrote:
 Your .fossil file contains information on which files are locally
 changed. The vfile table rememberd rid's for each file which
 is in the current checkout. Those rid's are searched in
 the blob table in your recepsum.fossil database.

 My guess is that you re-cloned recepsum.fossil and wrote
 it over the original recepsum.fossil file. This can result in
 chaned rid's, so the rid's in your .fossil file doesn't match
 your recepsum.fossil any more. That could result in
 exactly the symptoms you are seeing.

 You can fix that with:
  fossil checkout f51f0cfb9eed704a0e92364e1e6ea5d6d97c2365 --keep

 (The uuid is from the checkout line for your fossil stat)

Thank you!  I think you're probably right about what happened.

-- 
Will

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


[fossil-users] Changing file name and creating old file name at same time causes potential problem

2014-05-13 Thread Marty
On the trunk, User A renames foo.txt to foobar.txt (using the mv 
command). Then User A immediately creates a new file called foo.txt 
(uses the add command). After this and other file changes, a commit is 
performed. All appears fine.


User B and User C are working on their branches. User B merges with the 
trunk, and their existing copy of foo.txt is deleted by Fossil during 
the merge. foo.txt remains on the trunk for all to see, but User B 
cannot get it from a merge.


User C also does a merge with the trunk, but Fossil does not delete 
foo.txt in their case. So foo.txt and foobar.txt is added to their 
branch just fine.


User B (after much consternation) must checkout the trunk and merge with 
selected commits from their branch in order to get their work into the 
trunk.



Seems like there's a bug somewhere, but maybe there was an improper 
sequence of user events?




Marty Backe

___
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] Changing file name and creating old file name at same time causes potential problem

2014-05-13 Thread Andy Bradford
Thus said Marty on Tue, 13 May 2014 16:34:29 -0700:

 Seems like  there's a bug somewhere,  but maybe there was  an improper
 sequence of user events?

Seems like a bug to me.

Here is what I see:

$ fossil merge trunk
MERGE foo.txt
RENAME foo.txt - foobar.txt
 fossil undo is available to undo changes to the working checkout.
$ ls
foobar.txt
$ fossil status
repository:   /tmp/clone2/../clone2.fossil
local-root:   /tmp/clone2/
config-db:/home/amb/.fossil
checkout: 73951fbf2fd19417ddf4b6c9d877b7be6854d32a 2014-05-14 00:31:20 UTC
parent:   2090599c2fec41329a4575da8af0f0feb9fa08ba 2014-05-14 00:27:31 UTC
leaf: open
tags: nineteen
comment:  ninetee (user: amb)
EDITED foobar.txt
MERGED_WITH 03764343bf2b76127272b251db39498f61ac31c1
$ fossil ci -m test
Autosync:  http://amb@remote:8080/
Round-trips: 1   Artifacts sent: 0  received: 0
Pull finished with 335 bytes sent, 1096 bytes received
New_Version: f582b4d8ae4f24369b6e1c444ab6375ff0e7f9a1
Autosync:  http://amb@remote:8080/
Round-trips: 1   Artifacts sent: 2  received: 0
Sync finished with 1382 bytes sent, 1146 bytes received

Now, if I look at the manifest for f582b4d8ae4f24369b6e1c444ab6375ff0e7f9a1

C test
D 2014-05-14T00:33:05.374
F foobar.txt 499805f9bda9104664e5ea6e2775fbced255a080 w foo.txt
P 73951fbf2fd19417ddf4b6c9d877b7be6854d32a 
03764343bf2b76127272b251db39498f61ac31c1
R d278be014f44cc6f10bb55ddd24e9fd3
U amb
Z 5ee9592ecc6458755a9852b762f9c80b

Indeed   it   didn't   include   foo.txt,   so   it   silently   removed
foo.txt   from   the   checkin.   It   picked   up   the   rename   from
03764343bf2b76127272b251db39498f61ac31c1 and it should have included the
foo.txt from the same but didn't for some reason.

Andy
-- 
TAI64 timestamp: 40005372bc5a


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