Re: [fossil-users] question about background colour in Fossil/Chiselapp access log

[Will Parsons]

On Tuesday, 24 Apr 2018  9:28 PM -0400, Richard Hipp wrote:
> On 4/24/18, Will Parsons  wrote:
>> I use Chiselapp to host several of my fossil repositories, and I'm
>> puzzled to see that in the Access Log of one of my repositories on
>> Chisel that some (but only some) of the entries have a pink
>> background.
>
> I think those are failed login attempts - where the user entered an
> incorrect username or password.

Hmm... I guess that would make sense, and correlate with my seeing a
sequence of pink entries culminated in a white entry in the same day.

-- 
Will

___
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] question about background colour in Fossil/Chiselapp access log

[Richard Hipp]

On 4/24/18, Will Parsons  wrote:
> I use Chiselapp to host several of my fossil repositories, and I'm
> puzzled to see that in the Access Log of one of my repositories on
> Chisel that some (but only some) of the entries have a pink
> background.

I think those are failed login attempts - where the user entered an
incorrect username or password.

>
> I don't see anything obviously distinctive between the entries with a
> pink background and those with a white background in the Access Log,
> so I'm puzzled about the difference in appearance.
>
> (The Access Log of the same repository on my local machine looks
> different in various ways, and does not exhibit any difference in
> background colour among the entries.)
>
> --
> Will
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] question about background colour in Fossil/Chiselapp access log

[Will Parsons]

On Tuesday, 24 Apr 2018  9:03 PM -0400, Will Parsons wrote:
> I use Chiselapp to host several of my fossil repositories, and I'm
> puzzled to see that in the Access Log of one of my repositories on
> Chisel that some (but only some) of the entries have a pink
> background.
>
> I don't see anything obviously distinctive between the entries with a
> pink background and those with a white background in the Access Log,
> so I'm puzzled about the difference in appearance.
>
> (The Access Log of the same repository on my local machine looks
> different in various ways, and does not exhibit any difference in
> background colour among the entries.)

Well, there's nothing like asking a question to help one figuring out
the answer oneself.  On further examination, it looks like the pink
background indicates earlier logins on the same day, i.e, if there are
multiple logins on the same day, then all but the last seem to have
the pink background.

At least, that's what it *looks* like.  I would still like to have
confirmation of my deduction, and perhaps a pointer to where this
configuration setting is actually set.

-- 
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] question about background colour in Fossil/Chiselapp access log

[Will Parsons]

I use Chiselapp to host several of my fossil repositories, and I'm
puzzled to see that in the Access Log of one of my repositories on
Chisel that some (but only some) of the entries have a pink
background.

I don't see anything obviously distinctive between the entries with a
pink background and those with a white background in the Access Log,
so I'm puzzled about the difference in appearance.

(The Access Log of the same repository on my local machine looks
different in various ways, and does not exhibit any difference in
background colour among the entries.)

-- 
Will

___
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] question regarding fuel-scm maintenance / ownership

[Chris Drexler]

Am 27.12.2017 um 17:37 schrieb Olivier Mascia:
> What Fossil version(s) does Fuel works with?

I haven't seen a definitive list but I'm currently using the latest 2.4
(downloaded from fossil HP). So far I never had issues with whatever
fossil version I was using since 1.34 (or so), so I never cared :-).

Fuel is only using stdout parsing. It might also not support all
(newest) features, but it's very nice for the starters.

chris
___
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] question regarding fuel-scm maintenance / ownership

[Olivier Mascia]

> Le 27 déc. 2017 à 17:25, Chris Drexler  a écrit :
> 
>> If you are unable to make contact, you might consider "forking" the project 
>> (under a new name) and maintaining it yourself.
> 
> The project is currently available at 
> 
> https://server.ac-drexler.de/fossil/fuel
> 
> if anyone is interested.

What Fossil version(s) does Fuel works with?

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia


___
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] question regarding fuel-scm maintenance / ownership

[Chris Drexler]

Am 27.12.2017 um 04:39 schrieb Ron W:
> If you are unable to make contact, you might consider "forking" the
> project (under a new name) and maintaining it yourself.

The project is currently available at

    https://server.ac-drexler.de/fossil/fuel

if anyone is interested.

Chris
___
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] question regarding fuel-scm maintenance / ownership

[Chris Drexler]

Hi *,

Am 27.12.2017 um 16:19 schrieb Warren Young:
> On Dec 26, 2017, at 8:39 PM, Ron W  wrote:
>> If you are unable to make contact, you might consider "forking" the project 
>> (under a new name) and maintaining it yourself.
> If it’s truly abandoned, you generally want to keep the name, unless it’s 
> trademarked or “bad” in some way.  A better reason to change the name is when 
> you fork it while the original developer continues on with the project under 
> the same old name.
thanks for your suggestions, I found a contact adress in the PKGBUILD
file so I try to contact the author and see what his view is on his
project.

> I guess it’s supposed to evoke “refined fossils”, and also fuel for your 
> software development efforts?  If so, points for being cute.
I'm not sure of the reasons, but I thought in the same direction(s) :-).
Not too bad in conjunction with fossil, but too general to search for.
But I also have to search for "fossil scm" to not get to many hits on
watches ;-)

Chris
___
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] question regarding fuel-scm maintenance / ownership

[Warren Young]

On Dec 26, 2017, at 8:39 PM, Ron W  wrote:
> 
> If you are unable to make contact, you might consider "forking" the project 
> (under a new name) and maintaining it yourself.

If it’s truly abandoned, you generally want to keep the name, unless it’s 
trademarked or “bad” in some way.  A better reason to change the name is when 
you fork it while the original developer continues on with the project under 
the same old name.

“Fuel” isn’t the greatest of names.  It probably applies to a whole raft of 
other projects and non-software things.

I guess it’s supposed to evoke “refined fossils”, and also fuel for your 
software development efforts?  If so, points for being cute.

I myself run two previously-abandoned free software projects under their 
original names.
___
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] question regarding fuel-scm maintenance / ownership

[Ron W]

On Tue, Dec 26, 2017 at 7:00 AM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Mon, 25 Dec 2017 23:44:27 +0100
> From: Chris Drexler <ckolum...@ac-drexler.de>
> Subject: [fossil-users] question regarding fuel-scm maintenance /
> ownership
>
> Anyone here who knows any contact or has suggestions on what to do? I
> don't want to see this project die, I like fossil/fuel to propagate DVCS
> usage even to DVCS-newbies (like my son :-) ).
>

If you are unable to make contact, you might consider "forking" the project
(under a new name) and maintaining it yourself.
___
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] question regarding fuel-scm maintenance / ownership

[helpdeskkomandacard]

Здравствуйте!
Данный Вопрос не относится к программе лояльности.

С Уважением,
Программа лояльности «Семейная команда»




-Original Message-
From: fossil-users [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf 
Of helpdeskkomandacard
Sent: Tuesday, December 26, 2017 2:45 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] question regarding fuel-scm maintenance / ownership



Здравствуйте!
Данный Вопрос не относится к программе лояльности.

С Уважением,
Программа лояльности «Семейная команда»




-Original Message-
From: fossil-users [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf 
Of Chris Drexler
Sent: Tuesday, December 26, 2017 1:44 AM
To: fossil-us...@mailinglists.sqlite.org
Subject: [fossil-users] question regarding fuel-scm maintenance / ownership

Hi list,

sorry for asking here but I could not find a better place (yet). I'm currently 
updating fuel (https://fuel-scm.org/)  to compile with that latest Qt version 
and switching from it WebKit to WebEngine.
I can't get a hold of "Kostas", the original author of fuel-scm to ask about 
how to proceed further with this enhancement.

Anyone here who knows any contact or has suggestions on what to do? I don't 
want to see this project die, I like fossil/fuel to propagate DVCS usage even 
to DVCS-newbies (like my son :-) ).

Thanks ,
Chris

PS: if anyone's interested right now I can also provide access to my code 
and/or binaries for linux & windows

___
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] question regarding fuel-scm maintenance / ownership

[helpdeskkomandacard]

Здравствуйте!
Данный Вопрос не относится к программе лояльности.

С Уважением,
Программа лояльности «Семейная команда»




-Original Message-
From: fossil-users [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf 
Of Chris Drexler
Sent: Tuesday, December 26, 2017 1:44 AM
To: fossil-us...@mailinglists.sqlite.org
Subject: [fossil-users] question regarding fuel-scm maintenance / ownership

Hi list,

sorry for asking here but I could not find a better place (yet). I'm currently 
updating fuel (https://fuel-scm.org/)  to compile with that latest Qt version 
and switching from it WebKit to WebEngine.
I can't get a hold of "Kostas", the original author of fuel-scm to ask about 
how to proceed further with this enhancement.

Anyone here who knows any contact or has suggestions on what to do? I don't 
want to see this project die, I like fossil/fuel to propagate DVCS usage even 
to DVCS-newbies (like my son :-) ).

Thanks ,
Chris

PS: if anyone's interested right now I can also provide access to my code 
and/or binaries for linux & windows

___
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] question regarding fuel-scm maintenance / ownership

[Chris Drexler]

Hi list,

sorry for asking here but I could not find a better place (yet). I'm
currently updating fuel (https://fuel-scm.org/)  to compile with that
latest Qt version and switching from it WebKit to WebEngine.
I can't get a hold of "Kostas", the original author of fuel-scm to ask
about how to proceed further with this enhancement.

Anyone here who knows any contact or has suggestions on what to do? I
don't want to see this project die, I like fossil/fuel to propagate DVCS
usage even to DVCS-newbies (like my son :-) ).

Thanks ,
Chris

PS: if anyone's interested right now I can also provide access to my
code and/or binaries for linux & windows

___
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] Question about the file formats.

[Scott Robison]

On Dec 20, 2016 10:59 PM, "John Found"  wrote:

Well, the compression is the last thing I am talking about. It is
important, but not essential.

I am talking about several people working on one file and then fossil
merging the
changes automatically (of course if there is no conflicts in the edits).


I think the answer to your question is that merging depends on a knowledge
of the structure of data in order to detect where conflicts do or do not
exist. The structure of text files is "an ordered sequence of variable
length records" and the merge algorithm sees non overlapping changes as
independent. This is not always true, but it works often enough to be
useful. Because it is not always true, it is important to test post merge &
pre commit.

The merge algorithm could be modified to work with other data structures
but it would still require the property that non overlapping changes be
independent (have no impact on previous or future data). With a "binary"
format there are many other things that could go wrong. Fixed length
records, specific requirements for alignment, embedded non symbolic
references to other parts of the file are the first few that come to mind.

Without specific knowledge of the structure of the data, merge can't work.
Even with knowledge of the structure of text files, it can still get things
wrong.
___
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] Question about the file formats.

[Joerg Sonnenberger]

On Tue, Dec 20, 2016 at 08:48:27PM +0200, John Found wrote:
> What makes the binary files different from the text files? The presence or 
> absence of
> 0 bytes does not seems to make serious difference for processing by the same 
> algorithms.

Many text formats allow merging changes from one version to another with
minimal context. E.g. let's say you start from a C file and modify a line
in the middle in your checkout and then update your tree. Someone else
added a new function at the beginning of the file. This creates a
conflict and Fossil will try to resolve it by finding the context of the
line you modified in a similiar place and then readd that change. While
this doesn't work all the time for text files, it has a high chance of
working. Even if it doesn't work i.e. because the changes overlap, it
provides enough information that a user can typically do the same.

The same kind of tooling could be provided for binary formats, but it is
rarely exist directly.

Joerg
___
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] Question about the file formats.

[Stephan Beal]

On Dec 21, 2016 10:57 AM, "Warren Young"  wrote:


That is exactly what I’m talking about in my BMP vs PNG examples.

If you wish to discuss a different file type than than bitmap graphics,
give your own example.  Until then, mine is the only concrete example we
have available to discuss.


Zip files and similar archives apply here as well, i think (that includes
modern office suite formats,  many of which are zip files).  Without
knowing how to dissect them and diff the individual components, it can only
perform generic binary delta compression. i opine, without any proof to
back it up, that the compression  results would not be appreciably better
were fossil to "know" about such content (for most common file formats),
while performance, complexity, and memory costs would be negatively
impacted.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
___
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] Question about the file formats.

[John Found]

Well, the compression is the last thing I am talking about. It is important, 
but not essential.

I am talking about several people working on one file and then fossil merging 
the
changes automatically (of course if there is no conflicts in the edits).


On Tue, 20 Dec 2016 16:58:18 -0700
Warren Young  wrote:

> On Dec 20, 2016, at 3:57 PM, Warren Young  wrote:
> > 
> >> What if I design some text file format (containing only ascii characters) 
> >> and
> >> it can't be properly processed by fossil?
> > 
> > Then you should post it as a replicable test case for our study.
> 
> I decided to take up my own challenge.  Consider:
> 
> ## Create new repo; note initial size
> $ f init ../x.fossil
> $ ls -lh ../x.fossil 
> -rw-r--r--  1 me   group   212K Dec 20 16:13 ../x.fossil
> 
> ## Go grab a free PNG file, and re-save it with Photoshop’s
> ## Save for Web function to reduce unnecessary differences
> $ wget 
> https://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Topographic_Map_of_Bulgaria_Bulgarian.png/120px-Topographic_Map_of_Bulgaria_Bulgarian.png
> $ open -a 'Adobe Photoshop CC 2017' 
> 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
> $ ls -lh 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
> -rw-r--r--  1 me   group23K Dec 20 16:12 
> 120px-Topographic_Map_of_Bulgaria_Bulgarian.png
> 
> ## Add it to repo; notice that repo size goes up by 20 kB,
> ## showing that Fossil’s internal compression managed to
> ## squeeze an additional 3 kB over what Photoshop gives,
> ## probably due to metadata compression
> $ f add 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
> $ f ci -m initial
> $ f rebuild --compress --vacuum
> $ ls -lh ../x.fossil 
> -rw-r--r--  1 me   group   232K Dec 20 16:13 ../x.fossil
> 
> ## Change upper left corner pixel, amounting to only several
> ## bits of difference in the raw data
> $ open -a 'Adobe Photoshop CC 2017' 
> 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
> $ ls -lh 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
> -rw-r--r--  1 me   group23K Dec 20 16:14 
> 120px-Topographic_Map_of_Bulgaria_Bulgarian.png
> 
> ## Check change in; notice that roughly a dozen bits of change in
> ## the raw data became 28 kB of difference in the repo size!
> $ f ci -m '1 px change’
> $ f rebuild --compress --vacuum
> $ ls -lh ../x.fossil 
> -rw-r--r--  1 me   group   260K Dec 20 16:14 ../x.fossil
> 
> 
> Repeating that test with TIFF and PSD files didn’t give as small a difference 
> in the resulting Fossil repos size between checkins as I’d expected, but on 
> investigating I found that Photoshop writes a bunch of stuff into the 
> metadata that change on every save (e.g. timestamps, UUIDs…) which balloons 
> the diffs.  
> 
> Switching to Windows BMP fixes this: a 1px change results in a negligible 
> change in the repo size, because only about a dozen bits change in the raw 
> data.  (Windows BMP has very little metadata.)
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
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] Question about the file formats.

[Warren Young]

On Dec 20, 2016, at 3:57 PM, Warren Young  wrote:
> 
>> What if I design some text file format (containing only ascii characters) and
>> it can't be properly processed by fossil?
> 
> Then you should post it as a replicable test case for our study.

I decided to take up my own challenge.  Consider:

## Create new repo; note initial size
$ f init ../x.fossil
$ ls -lh ../x.fossil 
-rw-r--r--  1 me   group   212K Dec 20 16:13 ../x.fossil

## Go grab a free PNG file, and re-save it with Photoshop’s
## Save for Web function to reduce unnecessary differences
$ wget 
https://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Topographic_Map_of_Bulgaria_Bulgarian.png/120px-Topographic_Map_of_Bulgaria_Bulgarian.png
$ open -a 'Adobe Photoshop CC 2017' 
120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
$ ls -lh 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
-rw-r--r--  1 me   group23K Dec 20 16:12 
120px-Topographic_Map_of_Bulgaria_Bulgarian.png

## Add it to repo; notice that repo size goes up by 20 kB,
## showing that Fossil’s internal compression managed to
## squeeze an additional 3 kB over what Photoshop gives,
## probably due to metadata compression
$ f add 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
$ f ci -m initial
$ f rebuild --compress --vacuum
$ ls -lh ../x.fossil 
-rw-r--r--  1 me   group   232K Dec 20 16:13 ../x.fossil

## Change upper left corner pixel, amounting to only several
## bits of difference in the raw data
$ open -a 'Adobe Photoshop CC 2017' 
120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
$ ls -lh 120px-Topographic_Map_of_Bulgaria_Bulgarian.png 
-rw-r--r--  1 me   group23K Dec 20 16:14 
120px-Topographic_Map_of_Bulgaria_Bulgarian.png

## Check change in; notice that roughly a dozen bits of change in
## the raw data became 28 kB of difference in the repo size!
$ f ci -m '1 px change’
$ f rebuild --compress --vacuum
$ ls -lh ../x.fossil 
-rw-r--r--  1 me   group   260K Dec 20 16:14 ../x.fossil


Repeating that test with TIFF and PSD files didn’t give as small a difference 
in the resulting Fossil repos size between checkins as I’d expected, but on 
investigating I found that Photoshop writes a bunch of stuff into the metadata 
that change on every save (e.g. timestamps, UUIDs…) which balloons the diffs.  

Switching to Windows BMP fixes this: a 1px change results in a negligible 
change in the repo size, because only about a dozen bits change in the raw 
data.  (Windows BMP has very little metadata.)
___
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] Question about the file formats.

[Warren Young]

On Dec 20, 2016, at 12:35 PM, John Found  wrote:
> 
> Under "fossil algorithms" I mean two (in my understanding most important in 
> what is called "version control": diff algorithm and 3-way merge algorithm.

When I said that Fossil can’t diff two binary files, I meant that it couldn’t 
display a sensible difference to the terminal when you give the “fossil diff” 
command.  However, Fossil *can store* the difference between any two files, 
regardless of binary vs. text, as I suggested with my uncompressed TIFF example.

Fossil will even do so for files like PNGs where the worst case is that a 
single bit change in the original file could potentially change every byte in 
the output file, making the internal diffs Fossil stores very large, possibly 
to the point that there’s no value in delta compression at all, so that Fossil 
must simply store both versions in toto.  But Fossil will store those versions, 
and retrieve them.

As for merging, as long as the two versions Fossil is trying to merge have 
sufficient context between the changes to safely do the merge automatically, 
Fossil will do so.

Just as with diffing, if you use compression or encryption or otherwise cause 
the merged parts to overlap, Fossil won’t be able to do the merge automatically.

This is no different for what we choose to call “text” files, where if two 
users make a change to the same area of a single file, chances are high that 
Fossil will refuse to attempt an automatic merge, since there isn’t enough 
context between the changes for Fossil to be sure it isn’t creating a mess in 
the merge area.

> Or what makes the 3-way merge algorithm not working on binary files.

Except for whole-file compression and similar cases (e.g. pre-checkin 
encryption) I don’t think you can create a replicable test that shows that it 
doesn’t work.

> What if I design some text file format (containing only ascii characters) and
> it can't be properly processed by fossil?

Then you should post it as a replicable test case for our study.  Until you can 
do both things — i.e. cause a problem and create a replicable test case for it 
— you’re just speculating.

> Another example: Every binary file can be BASE64 encoded and it will be 
> turned into a 
> valid text file. Fossil will not detect it as a binary. But whether this file 
> will be
> processed properly on diffs and merges? Probably not. But why?

I don’t believe such an encoding will have a meaningful effect on any test, 
except that it effectively adds newlines every 70-some characters, where the 
original binary data might not have it, so “binary” data would now be detected 
as “text” data.

But, if the problem is that delta compression is inefficient with a given 
binary file because nearly every byte changes when you change just one small 
bit of the input file, then the same will be true of the Base64-encoded version.
___
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] Question about the file formats.

[Andy Bradford]

Thus said John Found on Tue, 20 Dec 2016 21:35:44 +0200:

> For example, I  can't see what is  the problem to make  diff of binary
> files.  As  a  result  one  will  have  the  bytes  that  have  to  be
> inserted/deleted from  the first  file in  order to  turn it  into the
> second. (Or I am wrong and that is why I ask such vague questions).

It certainly is  possible, though not currently implemented as  far as I
know. The binary diff can be  described simply as the deltas required to
get from A to B. You might experiment with the following test commands:

test-delta
test-delta-analyze
test-delta-apply
test-delta-create

It would seem that what you're asking for is a binary patch that perhaps
takes advantage  of the delta  encoding algorithm? This  would certainly
require a special binary that understands  the format of the data, but I
don't see why this shouldn't be possible.

I believe Fossil  stores the baseline and deltas going  back in time, so
to open  the most  recent version  of a  file, it  just gets  the latest
artifact, but to get older versions, it has to apply deltas.

Perhaps the following will address some of your questions:

http://www.fossil-scm.org/index.html/doc/trunk/www/delta_format.wiki
http://www.fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.wiki
http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki


> Or what makes  the 3-way merge algorithm not working  on binary files.
> The line organization of the text files? Something else?

I'm not sure  what it uses for  binary files, but there  is definitely a
delta component being  generated and stored. As a test,  I added a large
binary AVI to a fossil.

Before:

SIZE DATE FILE
217088   Dec 20 14:47 new.fossil
15155678 Dec 20 14:48 MVI_7509.AVI

After:

15171584 Dec 20 14:48 new.fossil

I then used vi to update a few bytes in the file and committed:

30117888 Dec 20 14:49 new.fossil

It did double in  size (not sure why, but I suspect  it has something to
do with establishing a baseline for the delta). But, I repeated the edit
with vi  and changed additional  other bytes,  but this time,  it didn't
grow very much at all:

30121984 Dec 20 14:50 new.fossil

And again:

30130176 Dec 20 14:54 new.fossil

So it is clearly efficiently storing them.

Experimenting with the test-delta-create command, I get:

15155678 Dec 20 15:12 MVI_7509.AVI.first
15155695 Dec 20 15:13 MVI_7509.AVI.second

$ fossil test-delta-create MVI_7509.AVI.first MVI_7509.AVI.second 
MVI_7509.AVI.delta

66   Dec 20 15:14 MVI_7509.AVI.delta

So the delta is only 66 bytes:

$ cat MVI_7509.AVI.delta 
up7k
3sQ@0,2:ab4yT@3sQ,4:zzjkf2@8pr,5:djfjkufdb@9Ut,5:
fff
37s_Sf;

Could I  share this  with someone?  Sure. They  could then  use ``fossil
test-delta-apply'' to use the ``patch.''


> What  if  I  design  some  text file  format  (containing  only  ascii
> characters) and it can't be properly processed by fossil?

If it contains  only ASCII characters then Fossil will  have no problems
handling  it  as a  text  file.  It  won't  matter what  arrangement  of
characters you place in such a file because they will be only ASCII.


> Another example: Every  binary file can be BASE64 encoded  and it will
> be turned  into a  valid text  file. Fossil  will not  detect it  as a
> binary. But whether this file will  be processed properly on diffs and
> merges?

Sure, you'll  get an ASCII  diff of the file,  but it won't  really mean
much to describe  the BASE64 diff between two files,  however, if that's
what you want, commit all binaries  as BASE64 encoded files. Then you'll
have to  BASE64 decode the file  as part of your  ``build'' process, and
you can even send patches/diffs of them.

Andy
-- 
TAI64 timestamp: 40005859adef


___
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] Question about the file formats.

[John Found]

I am not talking about the fossil heuristics in detection of what file is 
binary and
what file is text. Imagine all detection is switched off.

Under "fossil algorithms" I mean two (in my understanding most important in 
what is called "version control": diff algorithm and 3-way merge algorithm.

For example, I can't see what is the problem to make diff of binary files. As a 
result
one will have the bytes that have to be inserted/deleted from the first file in 
order to
turn it into the second. (Or I am wrong and that is why I ask such vague 
questions).

Or what makes the 3-way merge algorithm not working on binary files. The line 
organization of the text files? Something else?

What if I design some text file format (containing only ascii characters) and
it can't be properly processed by fossil?

Another example: Every binary file can be BASE64 encoded and it will be turned 
into a 
valid text file. Fossil will not detect it as a binary. But whether this file 
will be
processed properly on diffs and merges? Probably not. But why?


On Tue, 20 Dec 2016 12:13:43 -0700
Warren Young  wrote:

> On Dec 20, 2016, at 11:48 AM, John Found  wrote:
> > 
> > I know that fossil (and most other version control systems) can handle 
> > properly
> > only text source files. 
> 
> Says who?
> 
> There are some features of Fossil that simply don’t work when given a binary 
> file, like “fossil diff,” but if you think this is a missing feature (or even 
> a bug!) I’d have to ask how you think it should work?
> 
> Consider the case of a PNG.  How would you expect “fossil diff” to show the 
> difference between two PNGs?
> 
> Now multiply by the number of other binary file formats.
> 
> It is also the case that checking in compressed binary files is generally a 
> mistake, since that will largely defeat the built-in diffing and compression 
> mechanisms in Fossil, bloating the repository on every checkin.
> 
> (For some use cases, you can now avoid this problem with the new unversioned 
> files feature.)
> 
> Both of those classes of problem aside, Fossil will certainly accept “binary” 
> files. 
> 
> > What makes the binary files different from the text files? The presence or 
> > absence of
> > 0 bytes does not seems to make serious difference for processing by the 
> > same algorithms.
> 
> Fossil uses a heuristic to decide if a given file is “binary” or not, and it 
> has more to do with the chance that it will display properly when served to a 
> web browser than anything else.
> 
> Because it is a heuristic, it is possible to trick it.  For example, very 
> long text lines may be misdetected as a “binary” file, because it runs out of 
> buffer space looking for the first line terminator.
> 
> > What properties a file format needs in order to be processed properly by 
> > fossil?
> 
> Give a specific use case.  The answer differs depending on what Fossil 
> commands you want to be able to use on the files you check in.
> 
> I gave the “diff” case above, but that is not the only command that changes 
> behavior depending on whether the binary file heuristic decides that the file 
> is “binary.”
> 
> I’m putting “binary” in quotes because it is not a clear-cut distinction.  
> For Fossil’s purposes, an uncompressed TIFF is “less binary” than a PNG file, 
> because it is possible to do useful levels of delta compression on the TIFF 
> but not on the PNG.
> 
> > Is it enough for a file to contains only utf-8 characters or some other 
> > properties are
> > mandatory as well?
> 
> If you want to know the heuristic’s current implementation details, study 
> looks_like_utf8() in src/lookslike.c.
> 
> (There is also a UTF-16 version of that function, typically needed on 
> Windows.)
> 
> > Is it possible to define such binary file format that to be properly 
> > processed
> > by fossil (of course, after removing the explicit binary file checks)?
> > 
> > Or the opposite question: Is it possible to compose such text file that to 
> > not be
> > processed properly by fossil algorithms?
> 
> Both questions should be answered by a study of that heuristic function.
> 
> If you have further questions, make your questions more specific.  Your 
> current questions are so vague that I can give the answer “Yes” to both, and 
> be correct.  Not useful, I realize, but correct. :)
> ___

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
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] Question about the file formats.

[Warren Young]

On Dec 20, 2016, at 11:48 AM, John Found  wrote:
> 
> I know that fossil (and most other version control systems) can handle 
> properly
> only text source files. 

Says who?

There are some features of Fossil that simply don’t work when given a binary 
file, like “fossil diff,” but if you think this is a missing feature (or even a 
bug!) I’d have to ask how you think it should work?

Consider the case of a PNG.  How would you expect “fossil diff” to show the 
difference between two PNGs?

Now multiply by the number of other binary file formats.

It is also the case that checking in compressed binary files is generally a 
mistake, since that will largely defeat the built-in diffing and compression 
mechanisms in Fossil, bloating the repository on every checkin.

(For some use cases, you can now avoid this problem with the new unversioned 
files feature.)

Both of those classes of problem aside, Fossil will certainly accept “binary” 
files. 

> What makes the binary files different from the text files? The presence or 
> absence of
> 0 bytes does not seems to make serious difference for processing by the same 
> algorithms.

Fossil uses a heuristic to decide if a given file is “binary” or not, and it 
has more to do with the chance that it will display properly when served to a 
web browser than anything else.

Because it is a heuristic, it is possible to trick it.  For example, very long 
text lines may be misdetected as a “binary” file, because it runs out of buffer 
space looking for the first line terminator.

> What properties a file format needs in order to be processed properly by 
> fossil?

Give a specific use case.  The answer differs depending on what Fossil commands 
you want to be able to use on the files you check in.

I gave the “diff” case above, but that is not the only command that changes 
behavior depending on whether the binary file heuristic decides that the file 
is “binary.”

I’m putting “binary” in quotes because it is not a clear-cut distinction.  For 
Fossil’s purposes, an uncompressed TIFF is “less binary” than a PNG file, 
because it is possible to do useful levels of delta compression on the TIFF but 
not on the PNG.

> Is it enough for a file to contains only utf-8 characters or some other 
> properties are
> mandatory as well?

If you want to know the heuristic’s current implementation details, study 
looks_like_utf8() in src/lookslike.c.

(There is also a UTF-16 version of that function, typically needed on Windows.)

> Is it possible to define such binary file format that to be properly processed
> by fossil (of course, after removing the explicit binary file checks)?
> 
> Or the opposite question: Is it possible to compose such text file that to 
> not be
> processed properly by fossil algorithms?

Both questions should be answered by a study of that heuristic function.

If you have further questions, make your questions more specific.  Your current 
questions are so vague that I can give the answer “Yes” to both, and be 
correct.  Not useful, I realize, but correct. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question about the file formats.

[John Found]

Hi.

I know that fossil (and most other version control systems) can handle properly
only text source files. 

I am designing a format for my application and have some questions about the 
files handling. They are very related, but in different form:

What makes the binary files different from the text files? The presence or 
absence of
0 bytes does not seems to make serious difference for processing by the same 
algorithms.
Or it makes?

What properties a file format needs in order to be processed properly by fossil?
Is it enough for a file to contains only utf-8 characters or some other 
properties are
mandatory as well?

Is it possible to define such binary file format that to be properly processed
by fossil (of course, after removing the explicit binary file checks)?

Or the opposite question: Is it possible to compose such text file that to not 
be
processed properly by fossil algorithms?

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question about MERGE

[tonyp]

Today I tried something and got an unexpected result.  So, I would like to know 
what the right way would have been.

I created a new branch and made a whole bunch of changes.  Some of these 
changes were tested, and so I decided to merge them in to the trunk.

I did this by going to trunk, and the MERGE the other branch.  But, then, I 
REVerted the files whose changes I did not want included yet (as they are not 
fully tested).

I committed the result to the trunk.

Then I tried to merge that other branch again, and I expected to get the rest 
of the files merged in.  But, instead I got a no-op error.

So, how could I have this correctly?

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] Question about MERGE

[tonyp]

OK, but doesn't cherry-pick work the same as a MERGE but only for single 
version of the timeline?


My intent was to get all changes from the branch (the whole history) but for 
specific files, only.


-Original Message- 
From: Richard Hipp

Sent: Wednesday, October 28, 2015 6:00 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Question about MERGE

On 10/28/15, to...@acm.org <to...@acm.org> wrote:

Today I tried something and got an unexpected result.  So, I would like to
know what the right way would have been.

I created a new branch and made a whole bunch of changes.  Some of these
changes were tested, and so I decided to merge them in to the trunk.

I did this by going to trunk, and the MERGE the other branch.  But, then, 
I

REVerted the files whose changes I did not want included yet (as they are
not fully tested).

I committed the result to the trunk.

Then I tried to merge that other branch again, and I expected to get the
rest of the files merged in.  But, instead I got a no-op error.

So, how could I have this correctly?



Cherry-pick the changes you wanted to import.

When you did "fossil merge" that told Fossil that your intent was that
everything in the branch had been integrated into the trunk.  You went
back and undid some of those changes using "fossil revert", but Fossil
understood that to be your intent - that you wanted to abandon those
changes.

--
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] Question about MERGE

[Richard Hipp]

On 10/28/15, to...@acm.org  wrote:
> Today I tried something and got an unexpected result.  So, I would like to
> know what the right way would have been.
>
> I created a new branch and made a whole bunch of changes.  Some of these
> changes were tested, and so I decided to merge them in to the trunk.
>
> I did this by going to trunk, and the MERGE the other branch.  But, then, I
> REVerted the files whose changes I did not want included yet (as they are
> not fully tested).
>
> I committed the result to the trunk.
>
> Then I tried to merge that other branch again, and I expected to get the
> rest of the files merged in.  But, instead I got a no-op error.
>
> So, how could I have this correctly?
>

Cherry-pick the changes you wanted to import.

When you did "fossil merge" that told Fossil that your intent was that
everything in the branch had been integrated into the trunk.  You went
back and undid some of those changes using "fossil revert", but Fossil
understood that to be your intent - that you wanted to abandon those
changes.

-- 
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] Question about MERGE

[bch]

On 10/28/15, Richard Hipp  wrote:
> On 10/28/15, to...@acm.org  wrote:
>> OK, but doesn't cherry-pick work the same as a MERGE but only for single
>> version of the timeline?
>>
>> My intent was to get all changes from the branch (the whole history) but
>> for
>>
>
> Fossil does not currently support the ability to merge some files but
> not others.  That has never come up before.

I've certainly wished for the NOP operation that looks to be a side
effect of the [merge]/[revert] (and a cause of concern/confusion for
Tony). I tried to describe this to you years (6?) ago (without
success), but now I see I can get an effect of my original wish this
way... I'll see if I can dig out my original problem/paradigm, in case
it's enlightening.

-bch


>
> --
> 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] Question about MERGE

[Richard Hipp]

On 10/28/15, to...@acm.org  wrote:
> OK, but doesn't cherry-pick work the same as a MERGE but only for single
> version of the timeline?
>
> My intent was to get all changes from the branch (the whole history) but for
>

Fossil does not currently support the ability to merge some files but
not others.  That has never come up before.


-- 
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] Question about MERGE

[Matt Welland]

This is a surprisingly frequent need. Fossil is designed around a "get
things right the first time" philosophy but real life is often not that
crisp and clean. Being able to gracefully recover from mistakes and then
get rid of the irrelevant leftover cruft would be a wonderful addition to
fossil. I've used a methodology roughly like the following to handle this
kind of scenario:

define change-a as your single checkin containing two distinct changes
define change-a1 as part one of your two changes in change-a
define change-a2 as part two of your two changes in change-a

1. check out the common ancestor node
2. use meld or "fossil cat -r somever somefile > somefile" etc. to pull
change-a1
3. commit the change to a new branch change-a1-branch
4. repeat steps 1-3 for change-a2 creating change-a2-branch
5. close the change-a branch leaf, maybe hide it
6. create new branch change-a by merging change-a1 and change-a2
7. merge change-a1 to where they are needed

This is harder to describe than to do :)


On Wed, Oct 28, 2015 at 11:52 AM, bch  wrote:

> On 10/28/15, Richard Hipp  wrote:
> > On 10/28/15, to...@acm.org  wrote:
> >> OK, but doesn't cherry-pick work the same as a MERGE but only for single
> >> version of the timeline?
> >>
> >> My intent was to get all changes from the branch (the whole history) but
> >> for
> >>
> >
> > Fossil does not currently support the ability to merge some files but
> > not others.  That has never come up before.
>
> I've certainly wished for the NOP operation that looks to be a side
> effect of the [merge]/[revert] (and a cause of concern/confusion for
> Tony). I tried to describe this to you years (6?) ago (without
> success), but now I see I can get an effect of my original wish this
> way... I'll see if I can dig out my original problem/paradigm, in case
> it's enlightening.
>
> -bch
>
>
> >
> > --
> > 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] Question about fossil mv

[Zoltán Kócsi]

Can someone explain me how exactly fossil manages moves?

The actual problem is the following.

Let's have a project, foo, with the following structure:

foo/x/a.c
foo/x/b.c
foo/y/c.c
foo/y/d.c

The project sits on a central server. Two developers, Alice and Bob
have their local clones on their machine and checked out the project in
the above state.

Alice modifies a.c and c.c. In the meantime, Bob also edits
files, but different ones to those edited by Alice, so there are
no merge conflicts. However, Bob also decided to re-organise the
project source tree and moves files around, with 'fossil mv'. So now
they have the following state (capital filename indicates modified
file but of course the actual filename is lower case):

Alice:

foo/x/A.c
foo/x/B.c
foo/y/c.c
foo/y/d.c

Bob:

foo/z/q/a.c
foo/z/q/b.c
foo/z/q/C.c
foo/y/D.c

Now Alice commits to the server, and it goes through without a hitch.
The problem arises when Bob, before his commit wants to fossil update
(auto-sync is on).

At that point fossil seems to simply delete C.c (i.e. Bob's
modifications to that file are completely lost) *and* also, it seems,
Bob's moves are ignored - the original project structure is restored.
All that remains from Bob's work is his edits of d.c - D.c but
everything else he's done is gone.

In the real case where this happened we're not talking about 4 files
but hundreds, of which at least 20-30 have been moved around by Bob and
similar amount edited by both parties; re-doing the whole thing would
be a real PITA.

So, my questions are the following:

Fossil on Bob's machine can know that x/A.c on the server is the
modified version of Bob's z/q/a.c, so it could just change z/q/a.c to
z/q/A.c, i.e. merge Alice's file content change with Bob's file
location change. Considering that they are orthogonal, there's no merge
conflict. But even if Bob edited his a.c, fossil could just merge the
server's x/A.c with Bob's z/q/A.c, just as it would with an un-moved
file.

Question 1: is there a way to ask fossil to do that?

Question 2: why does fossil delete a modified file (C.c)? That, I
believe, is something that fossil was designed to never do. As far as I
know, fossil would under no circumstances discard unsaved work unless
the user explicitly and specifically instructs it to do so. It seems
that fossil mv can drive fossil into a state where it discards user
changes without confirmation - we needed to use fossil undo to restore
the mods when we realised what happened during fossil update.

Thanks,

Zoltan
___
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] Question on moving a repository (possible bug?)

[Robert Engelhardt]

Hello Richard,


[Issue with repository disappearing from the configuration database]
Please try with trunk.


Yes, this did resolve the issue! Thanks for the fast fix!
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question on moving a repository (possible bug?)

[Robert Engelhardt]

Hello,

I discovered something strange when moving repositories (I wanted to 
consolidate the location of some of mine). After some searching I came 
up with three possibilities for a repository relocation:


1) Simple moving the file and then updating the location both in the 
global configuration database as well as all checkout databases (which 
in my case would've been only one) via raw SQL commands.


2) Closing the checkout(s), moving the repository, and the re-opening 
the checkout(s).


3) Using the test-move-repository command (which I found in some of 
the archived list e-mails).


Is that correct, or are there more ways?

I considered variant 1 as too manual and too error-prone, and (despite 
the --force option for closing and the --keep option for re-opening) 
variant 2 has its disadvantages as well (like losing the undo history, 
the stash etc). Therefore I opted for variant 3.


The move was successful in the end, but after issuing the command, the 
repository disappeared from the list of all repositories in the 
configuration database, i.e., it was not contained in the fossil all 
list output anymore. Luckily, after doing the first commit, it 
reappeared again…


My questions here are:

• Does this happen on purpose or is this a bug? For me it seems odd that 
the repository gets (temporarily) lost from the list of all 
repositories and thus excluded from all fossil all commands until 
being added again later.


• If this is bug, why is it resolved by the first commit to the involved 
repository? My naive understanding is that a commit only affects the 
respective checkout database as well as of course the repository 
database itself, but not the global configuration database?


In case this is indeed a bug, I can file a ticket (though the issue is 
not critical due to its exceptional nature).


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] Question on moving a repository (possible bug?)

[Richard Hipp]

Please try with trunk.

On Tue, Dec 16, 2014 at 6:19 PM, Robert Engelhardt 
m...@robert-engelhardt.de wrote:

 Hello,

 I discovered something strange when moving repositories (I wanted to
 consolidate the location of some of mine). After some searching I came up
 with three possibilities for a repository relocation:

 1) Simple moving the file and then updating the location both in the
 global configuration database as well as all checkout databases (which in
 my case would've been only one) via raw SQL commands.

 2) Closing the checkout(s), moving the repository, and the re-opening the
 checkout(s).

 3) Using the test-move-repository command (which I found in some of the
 archived list e-mails).

 Is that correct, or are there more ways?

 I considered variant 1 as too manual and too error-prone, and (despite
 the --force option for closing and the --keep option for re-opening)
 variant 2 has its disadvantages as well (like losing the undo history, the
 stash etc). Therefore I opted for variant 3.

 The move was successful in the end, but after issuing the command, the
 repository disappeared from the list of all repositories in the
 configuration database, i.e., it was not contained in the fossil all list
 output anymore. Luckily, after doing the first commit, it reappeared again…

 My questions here are:

 • Does this happen on purpose or is this a bug? For me it seems odd that
 the repository gets (temporarily) lost from the list of all repositories
 and thus excluded from all fossil all commands until being added again
 later.

 • If this is bug, why is it resolved by the first commit to the involved
 repository? My naive understanding is that a commit only affects the
 respective checkout database as well as of course the repository database
 itself, but not the global configuration database?

 In case this is indeed a bug, I can file a ticket (though the issue is not
 critical due to its exceptional nature).

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



-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question about command line matching branch creation

[David J. Weller-Fahy]

I've been trying to puzzle this out myself, but decided someone must 
know on the list.


Assume I execute the following commands (with `alias f='fossil'`).

#v+
alias f='fossil'
f init ~/FOSSIL/1.fossil
f open ~/FOSSIL/1.fossil
touch 1
f add 1
f commit -m 1
mkdir 2
mkdir 3
cd 2
git init
touch a
touch b
touch c
git add a
git commit -m a a
git add b
git commit -m b b
git add c
git commit -m c c
git fast-export --all | f import --incremental --git ~/FOSSIL/1.fossil
#v-

At this point I have a single commit which was part of the original 
repository, and three commits *prior* to the original repository which 
were imported from git.


What I would like to do is imitate the results of the following.

Using the fossil ui command, access the timeline.  Click on the first 
commit imported from git.  Click on edit.  Replace the branch name with 
2.  Click Apply Changes.


I've tried using the branch command to create a new branch, and the tag 
command to tag the specified commits.  But I've been unable to duplicate 
the create of a new branch using the web-ui.


So, my question: What combination of commands would allow me to 
duplicate that on the command line?


Regards,
--
dave [ please don't CC me ]


pgpbempsmDrEx.pgp
Description: PGP signature
___
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] Question about command line matching branch creation

[David J. Weller-Fahy]

I just realized I never said:

$ f version
This is fossil version 1.30 [ffef4edceb] 2014-07-25 13:12:52 UTC

* David J. Weller-Fahy dave+lists.fossil-us...@caterva.org [2014-08-02 22:42 
-0500]:
I've been trying to puzzle this out myself, but decided someone must 
know on the list.


Assume I execute the following commands (with `alias f='fossil'`).


--
dave [ please don't CC me ]


pgpjxHRpULDR7.pgp
Description: PGP signature
___
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] Question regarding ancestors and Q-card relations.

[Richard Hipp]

On Wed, Jun 4, 2014 at 12:07 AM, Andy Bradford amb-fos...@bradfords.org
wrote:

 Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600:

  Does the Q-card here not imply any relation with c14a4a93d5a3 which will
  be picked  up in trunk?

 It seems I did not understand this very well:

 A Q-card is similar to a P-card in that it defines a predecessor
 to  the  current check-in.  But  whereas  a P-card  defines  the
 immediate ancestor  or a merge  ancestor, the Q-card is  used to
 identify a single  check-in or a small range  of check-ins which
 were  cherry-picked  for  inclusion  in or  exclusion  from  the
 current manifest.

 Which I suppose means that there is no ancestral relationship.



Right.  Q-cards are informational only and are not used by merge logic, or
currently for any other purpose.  At some point it would be nice to show
cherry-pick lines in the timeline graph, and for that the Q-cards will be
used.



  $ fossil merge c14a4a
  MERGE file
   fossil undo is available to undo changes to the working checkout.

 Should a merge  in this case result  in a conflict? Or is  it correct to
 merge in  the content  a second  time? Or should  it recognize  that the
 Q-card UUID and the UUID of the version being merged in are the same and
 include a warning or even error?



The merge logic in Fossil recognizes when the same exact change is merged
more than once and avoids conflicts in that case.  The Q-cards are not
necessary for 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

Re: [fossil-users] Question regarding ancestors and Q-card relations.

[Andy Bradford]

Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400:

 The merge  logic in Fossil  recognizes when  the same exact  change is
 merged more than  once and avoids conflicts in that  case. The Q-cards
 are not necessary for this.

What  am I  doing wrong  then?  In this  case,  I did  a cherrypick  and
committed to  get 738e72e3d9;  then right  after I  merge from  the same
checkin as the Q-card, but the diff shows that it duplicated the content
(I did not add the line in the diff, the merge did):

$ fossil stat | grep checkout
checkout: 738e72e3d9cfe5568c94940c09ada1b78341ac68 2014-06-04 03:48:59 UTC

$ fossil art 738e72e3d9cfe5568c94940c09ada1b78341ac68
C six
D 2014-06-04T03:48:59.091
F file 2dfb8ca405192b966ad859171e7a52141fa90d73
P 6b8b667ee4c9f7176410c90f99d0a43aa33f30b0
Q +c14a4a93d5a353f1a887b0ddd7c37f33ce45569f
R 36855f79a36bd6536f8584211e9077df
U amb
Z 03e53539308b57abb68256d198c87954

$ fossil merge c14a4a
MERGE file
 fossil undo is available to undo changes to the working checkout.

$ fossil diff
Index: file
==
--- file
+++ file
@@ -1,2 +1,3 @@
 21443
+3661
 3661

Thanks,

Andy
--
TAI64 timestamp: 4000538f5a94
___
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] Question regarding ancestors and Q-card relations.

[Richard Hipp]

On Wed, Jun 4, 2014 at 1:42 PM, Andy Bradford amb-fos...@bradfords.org
wrote:

 Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400:

  The merge  logic in Fossil  recognizes when  the same exact  change is
  merged more than  once and avoids conflicts in that  case. The Q-cards
  are not necessary for this.

 What  am I  doing wrong  then?  In this  case,  I did  a cherrypick  and
 committed to  get 738e72e3d9;  then right  after I  merge from  the same
 checkin as the Q-card, but the diff shows that it duplicated the content
 (I did not add the line in the diff, the merge did):


No merge is perfect.  Apparently you hit a bad case.  But I do similar
things all the time on actual source code and rarely have 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

[fossil-users] Question regarding ancestors and Q-card relations.

[Andy Bradford]

Hello,

While experimenting with --cherrypick I stumbled upon this situation:

$ fossil merge trunk
cannot find a common ancestor between the current checkout and trunk
$ f stat | grep checkout
checkout: 738e72e3d9cfe5568c94940c09ada1b78341ac68 2014-06-04 03:48:59 UTC
$ fossil artifact 738e72e3d9cfe5568c94940c09ada1b78341ac68
C six
D 2014-06-04T03:48:59.091
F file 2dfb8ca405192b966ad859171e7a52141fa90d73
P 6b8b667ee4c9f7176410c90f99d0a43aa33f30b0
Q +c14a4a93d5a353f1a887b0ddd7c37f33ce45569f
R 36855f79a36bd6536f8584211e9077df
U amb
Z 03e53539308b57abb68256d198c87954

Does the Q-card here not imply any relation with c14a4a93d5a3 which will
be picked  up in trunk?  After c14a4a93d5a3  there are two  more commits
which is  where trunk is  currently, yet when I  try to merge  it cannot
find a common ancestor.

If I  try to merge with  the checkin from  which I just cherry  picked I
get:

$ fossil merge c14a4a 
MERGE file
 fossil undo is available to undo changes to the working checkout.
$ fossil diff
Index: file
==
--- file
+++ file
@@ -1,2 +1,3 @@
 21443
+3661
 3661

So it added a second copy of the change?

Thanks,

Andy
-- 
TAI64 timestamp: 4000538e99bc


___
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] Question regarding ancestors and Q-card relations.

[Andy Bradford]

Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600:

 Does the Q-card here not imply any relation with c14a4a93d5a3 which will
 be picked  up in trunk?

It seems I did not understand this very well:

A Q-card is similar to a P-card in that it defines a predecessor
to  the  current check-in.  But  whereas  a P-card  defines  the
immediate ancestor  or a merge  ancestor, the Q-card is  used to
identify a single  check-in or a small range  of check-ins which
were  cherry-picked  for  inclusion  in or  exclusion  from  the
current manifest.

Which I suppose means that there is no ancestral relationship.

 $ fossil merge c14a4a 
 MERGE file
  fossil undo is available to undo changes to the working checkout.

Should a merge  in this case result  in a conflict? Or is  it correct to
merge in  the content  a second  time? Or should  it recognize  that the
Q-card UUID and the UUID of the version being merged in are the same and
include a warning or even error?

Andy
-- 
TAI64 timestamp: 4000538e9b89


___
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] question about parms and ownership of repo vs current/parent dir

[Andy Bradford]

Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:

 root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Error: Database error: unable to open database file: {CREATE TEMP
 TABLE onremote(rid INTEGER PRIMARY KEY);}
 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync finished with 638 bytes sent, 319 bytes received

I get a different error entirely:

# fossil sync new.fossil -R clone.fossil
server sends error: 
SQLITE_CANTOPEN: cannot open file at line 29670 of [d018a34a05]


SQLITE_CANTOPEN: os_unix.c:29670: (2) open(/new.fossil-journal) - No such file 
or directory


SQLITE_CANTOPEN: statement aborts at 22: [INSERT INTO 
config(name,value,mtime)VALUES('baseurl:http://',1,now())] 

Database Error
unable to open database file: {INSERT INTO 
config(name,value,mtime)VALUES('baseurl:http://',1,now())}
If you have recently updated your fossil executable, you might
need to run fossil all rebuild to bring the repository
schemas up to date.


Sync finished with 381 bytes sent, 835 bytes received

The  path  above  in  the open(/new.fossil-journal)  does  seem  like  a
chroot/user  permission issue  so  perhaps my  original suspicions  were
correct. I didn't think a file sync  would behave the same as others and
at  first  glance  in  the  code, it  doesn't  appear  to,  however,  it
definitely looks like this  might be the case. I'll see if  I can dig up
the actual cause.

Andy
-- 
TAI64 timestamp: 4000538820a8


___
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] question about parms and ownership of repo vs current/parent dir

[Andy Bradford]

Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:

 Can anyone tell what happens under the hood here..?

Bingo:

http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268

So it does indeed call ``fossil http'' which will cause fossil to chroot
and drop privileges depending on the owner of the file.

I see  from your email that  the permissions on /tmp/ftmp  are 755 which
means only root will be able to create/modify files in that directory:

root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x  2 root  wheel  512 May 29 15:33 .
-rw-r--r--  1 root  wheel  3435520 May 29 15:33 f_f
-rw-r--r--  1 root  wheel  3592192 May 29 15:33 r_w

Andy
-- 
TAI64 timestamp: 400053882443


___
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] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 30 May 2014 08:09, Andy Bradford
amb-sendok-1404022150.hdbpagcekdcgljghk...@bradfords.org wrote:
 Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:

 root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Error: Database error: unable to open database file: {CREATE TEMP
 TABLE onremote(rid INTEGER PRIMARY KEY);}
 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync finished with 638 bytes sent, 319 bytes received

 I get a different error entirely:

 ...

Thank you for testing. This looks almost exactly what I got here when
syncing, when the repos were not yet in sync.
I didn't post this error, because after getting the repos in sync
(eventually by changing permissions/ownership, then syncing), there
was still an error, which I posted. I thought the 'in sync' situation
was a nicer minimal testcase - I probably should have mentioned this
right at the start.

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 30 May 2014 08:24, Andy Bradford
amb-sendok-1404023072.eeipjlgjbincchjbb...@bradfords.org wrote:
 Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:

 Can anyone tell what happens under the hood here..?

 Bingo:

 http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268

 So it does indeed call ``fossil http'' which will cause fossil to chroot
 and drop privileges depending on the owner of the file.

 I see  from your email that  the permissions on /tmp/ftmp  are 755 which
 means only root will be able to create/modify files in that directory:

Ok, thanks for analysis. It looks like this (thread) explains
everything I saw here.

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

[fossil-users] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

Hello,

ran to something I didn't understand just now, and turned out to be
(likely) a thing concerning permissions.

In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:

root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x  2 root  wheel  512 May 29 15:32 .
-rw-r--r--  1 ftp   ftp3435520 May 29 15:32 f_f
-rw-r--r--  1 root  wheel  3592192 May 29 15:32 r_w
root@main:/tmp/ftmp# f sync r_w -R f_f
Round-trips: 1   Artifacts sent: 0  received: 0
Sync finished with 637 bytes sent, 615 bytes received
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1   Artifacts sent: 0  received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
Round-trips: 1   Artifacts sent: 0  received: 0
Sync finished with 638 bytes sent, 319 bytes received
root@main:/tmp/ftmp# chown root.wheel f_f
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x  2 root  wheel  512 May 29 15:33 .
-rw-r--r--  1 root  wheel  3435520 May 29 15:33 f_f
-rw-r--r--  1 root  wheel  3592192 May 29 15:33 r_w
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1   Artifacts sent: 0  received: 0
Sync finished with 635 bytes sent, 614 bytes received
root@main:/tmp/ftmp# f ver
This is fossil version 1.29 [87130593e4] 2014-05-26 20:55:57 UTC

Can anyone tell what happens under the hood here..?

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Richard Hipp]

On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers m.ramak...@gmail.com
wrote:

 Hello,

 ran to something I didn't understand just now, and turned out to be
 (likely) a thing concerning permissions.

 In short, syncing with repo seems to work or not depending of
 perms/ownership of that repo:

 root@main:/tmp/ftmp# ls -ld * .
 drwxr-xr-x  2 root  wheel  512 May 29 15:32 .
 -rw-r--r--  1 ftp   ftp3435520 May 29 15:32 f_f
 -rw-r--r--  1 root  wheel  3592192 May 29 15:32 r_w
 root@main:/tmp/ftmp# f sync r_w -R f_f
 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync finished with 637 bytes sent, 615 bytes received
 root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Error: Database error: unable to open database file: {CREATE TEMP
 TABLE onremote(rid INTEGER PRIMARY KEY);}


It is acting like you do not have write permission on /var/tmp.



 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync finished with 638 bytes sent, 319 bytes received
 root@main:/tmp/ftmp# chown root.wheel f_f
 root@main:/tmp/ftmp# ls -ld * .
 drwxr-xr-x  2 root  wheel  512 May 29 15:33 .
 -rw-r--r--  1 root  wheel  3435520 May 29 15:33 f_f
 -rw-r--r--  1 root  wheel  3592192 May 29 15:33 r_w
 root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync finished with 635 bytes sent, 614 bytes received
 root@main:/tmp/ftmp# f ver
 This is fossil version 1.29 [87130593e4] 2014-05-26 20:55:57 UTC

 Can anyone tell what happens under the hood here..?

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




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 29 May 2014 15:44, Richard Hipp d...@sqlite.org wrote:

 On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers m.ramak...@gmail.com
 wrote:

 In short, syncing with repo seems to work or not depending of
 perms/ownership of that repo:

 root@main:/tmp/ftmp# ls -ld * .
 drwxr-xr-x  2 root  wheel  512 May 29 15:32 .
 -rw-r--r--  1 ftp   ftp3435520 May 29 15:32 f_f
 -rw-r--r--  1 root  wheel  3592192 May 29 15:32 r_w
 root@main:/tmp/ftmp# f sync r_w -R f_f
 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync finished with 637 bytes sent, 615 bytes received
 root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Error: Database error: unable to open database file: {CREATE TEMP
 TABLE onremote(rid INTEGER PRIMARY KEY);}

 It is acting like you do not have write permission on /var/tmp.

drwxrwxrwt  4 root  wheel  512 May 29 15:33 /var/tmp

In the example above, I su'd root.

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Stephan Beal]

On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers m.ramak...@gmail.com
wrote:

 In short, syncing with repo seems to work or not depending of
 perms/ownership of that repo:

 root@main:/tmp/ftmp# ls -ld * .
 root@main:/tmp/ftmp# f sync r_w -R f_f
 ...

root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Error: Database error: unable to open database file: {CREATE TEMP
 TABLE onremote(rid INTEGER PRIMARY KEY);}


This is likely (i'm speculating!) a chroot-related problem, because (A)
root has (at the OS level) no permissions restrictions and (B) fossil
always chroot's when run as root. We recently had a bug where the current
dir was not being properly determined in a chroot case, and maybe (again,
speculating) there's a similar case which only triggers in this setup.

(Remember that fossil does not know about OS-level users, with the single
exception of the root user.)

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

Re: [fossil-users] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 29 May 2014 15:57, Stephan Beal sgb...@googlemail.com wrote:
 On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers m.ramak...@gmail.com
 wrote:

 In short, syncing with repo seems to work or not depending of
 perms/ownership of that repo:

 root@main:/tmp/ftmp# ls -ld * .
 root@main:/tmp/ftmp# f sync r_w -R f_f
 ...

 root@main:/tmp/ftmp# f sync f_f -R r_w
 Round-trips: 1   Artifacts sent: 0  received: 0
 Error: Database error: unable to open database file: {CREATE TEMP
 TABLE onremote(rid INTEGER PRIMARY KEY);}

 This is likely (i'm speculating!) a chroot-related problem, because (A) root
 has (at the OS level) no permissions restrictions and (B) fossil always
 chroot's when run as root.
 We recently had a bug where the current dir was
 not being properly determined in a chroot case, and maybe (again,
 speculating) there's a similar case which only triggers in this setup.

 (Remember that fossil does not know about OS-level users, with the single
 exception of the root user.)

Alright... I did not realise or forgot about always chrooting.

If anyone wants to pick this up, I would be happy to test/try. I'm
assuming it is easy to reproduce, although 'f_f' and 'r_w' were actual
repos here. (My issue here is long gone, mind - this was caused by
FTP'd repos.)

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Richard Hipp]

On Thu, May 29, 2014 at 9:57 AM, Stephan Beal sgb...@googlemail.com wrote:

  (B) fossil always chroot's when run as root.


That sounds right to me.  Running Fossil as root causes a chroot and
/var/tmp does not exist inside the chroot jail.

-- 
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] question about parms and ownership of repo vs current/parent dir

[Stephan Beal]

On Thu, May 29, 2014 at 4:11 PM, Richard Hipp d...@sqlite.org wrote:

 On Thu, May 29, 2014 at 9:57 AM, Stephan Beal sgb...@googlemail.com
 wrote:

  (B) fossil always chroot's when run as root.


 That sounds right to me.  Running Fossil as root causes a chroot and
 /var/tmp does not exist inside the chroot jail.


In this case, both syncs were run as root from the same dir, but the owner
of the repo is different in each. i don't remember ever seeing code which
uses file-level ownership to determine who is who, so i'm at a loss to
explain the behaviour difference.

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

Re: [fossil-users] question about parms and ownership of repo vs current/parent dir

[Andy Bradford]

Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:

 root@main:/tmp/ftmp# ls -ld * .
 drwxr-xr-x  2 root  wheel  512 May 29 15:32 .
 -rw-r--r--  1 ftp   ftp3435520 May 29 15:32 f_f
 -rw-r--r--  1 root  wheel  3592192 May 29 15:32 r_w
 root@main:/tmp/ftmp# f sync r_w -R f_f

When you run as root, it will  drop privileges to the user that owns the
named repository. I suspect  that in this case, f_f is  owned by ftp, so
it drops privileges to ftp but then is unable to write to r_w.

I could be wrong, but one thing you could try to verify is:

chown ftp.ftp r_w
f sync r_w -R f_f

Andy
-- 
TAI64 timestamp: 400053874612


___
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] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 29 May 2014 16:36, Andy Bradford
amb-sendok-1403966191.gpijlhaollnogheom...@bradfords.org wrote:
 Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:

 root@main:/tmp/ftmp# ls -ld * .
 drwxr-xr-x  2 root  wheel  512 May 29 15:32 .
 -rw-r--r--  1 ftp   ftp3435520 May 29 15:32 f_f
 -rw-r--r--  1 root  wheel  3592192 May 29 15:32 r_w
 root@main:/tmp/ftmp# f sync r_w -R f_f

 When you run as root, it will  drop privileges to the user that owns the
 named repository. I suspect  that in this case, f_f is  owned by ftp, so
 it drops privileges to ftp but then is unable to write to r_w.

 I could be wrong, but one thing you could try to verify is:

 chown ftp.ftp r_w
 f sync r_w -R f_f

In case both files are owned ftp.ftp and their parent-dir is owned
root.wheel, sync either way gives an error (instead of just 1 error in
the pasted shell dialog.)

In case both files as well as their parent-dir are owned ftp.ftp, both
syncs work fine.

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Stephan Beal]

On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
wrote:

 In case both files as well as their parent-dir are owned ftp.ftp, both
 syncs work fine.


If fossil drops permissions as Andy suggests (i'm still trying to find the
relevant code, but have no reason to believe he's wrong), then that's the
problem. It would go something like this:


chroot to /tmp/...
switch user to ftp
try to create a temp file somewhere under the new root
== no rights

Ah, here it is:

** If running as root, chroot to the directory containing the
** repository zRepo and then drop root privileges.  Return the
** new repository name.
**

if( stat(zRepo, sStat)!=0 ){
  fossil_fatal(cannot stat() repository: %s, zRepo);
}
i = setgid(sStat.st_gid);
i = i || setuid(sStat.st_uid);

sure enough. It switches back to the owning user/group of the repo.

IMO, that's not a bug, just an unfortunate side effect of your setup.

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

Re: [fossil-users] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 29 May 2014 17:08, Michai Ramakers m.ramak...@gmail.com wrote:
 On 29 May 2014 16:36, Andy Bradford
 amb-sendok-1403966191.gpijlhaollnogheom...@bradfords.org wrote:
 Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
 ...
 I could be wrong, but one thing you could try to verify is:

 chown ftp.ftp r_w
 f sync r_w -R f_f

 In case both files are owned ftp.ftp and their parent-dir is owned
 root.wheel, sync either way gives an error (instead of just 1 error in
 the pasted shell dialog.)

 In case both files as well as their parent-dir are owned ftp.ftp, both
 syncs work fine.

And... if one of the files is owned root.wheel, and the other file as
well as their parent-dir is owned ftp.ftp, both syncs works fine.

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Michai Ramakers]

On 29 May 2014 17:12, Stephan Beal sgb...@googlemail.com wrote:
 On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
 wrote:

 In case both files as well as their parent-dir are owned ftp.ftp, both
 syncs work fine.


 If fossil drops permissions as Andy suggests (i'm still trying to find the
 relevant code, but have no reason to believe he's wrong), then that's the
 problem. It would go something like this:

 chroot to /tmp/...
 switch user to ftp
 try to create a temp file somewhere under the new root
 == no rights

 Ah, here it is:

 ** If running as root, chroot to the directory containing the
 ** repository zRepo and then drop root privileges.  Return the
 ** new repository name.
 **

 if( stat(zRepo, sStat)!=0 ){
   fossil_fatal(cannot stat() repository: %s, zRepo);
 }
 i = setgid(sStat.st_gid);
 i = i || setuid(sStat.st_uid);

 sure enough. It switches back to the owning user/group of the repo.

 IMO, that's not a bug, just an unfortunate side effect of your setup.

Alright, thanks for looking into this (, all).
Does this also explain my last mail (in case one file is owned
root.wheel, and the other file and parent-dir are owned ftp.ftp, all
works fine)?

Michai
___
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] question about parms and ownership of repo vs current/parent dir

[Richard Hipp]

On Thu, May 29, 2014 at 11:12 AM, Stephan Beal sgb...@googlemail.com
wrote:

 On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
 wrote:

 In case both files as well as their parent-dir are owned ftp.ftp, both
 syncs work fine.


 If fossil drops permissions as Andy suggests (i'm still trying to find the
 relevant code, but have no reason to believe he's wrong), then that's the
 problem.


To find the code:  grep for setuid.

Fossil does drop permissions back to an unprivileged user when running as
root.  This is a security feature, to prevent a bug in Fossil from
providing root shell access to an attacker.  Also, root can break out of a
chroot jail, so the chroot jail is only effective for normal users.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] question about parms and ownership of repo vs current/parent dir

[Andy Bradford]

Thus said Michai Ramakers on Thu, 29 May 2014 17:08:52 +0200:

 In case both files as well as their parent-dir are owned ftp.ftp, both
 syncs work fine.

Sounds like a  simple case of permissions problems to  me. The user that
is running the  sync must have sufficient Unix  filesystem privileges to
be able to write to the fossil.

If you run as root, the privileges will drop to the owner of the fossil.
At that point,  whatever that user can  do should be doable,  but if the
directory is not writable by that user,  then fossil will not be able to
write to the fossil repo.

Andy
___
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] question about parms and ownership of repo vs current/parent dir

[Andy Bradford]

Thus said Stephan Beal on Thu, 29 May 2014 17:12:35 +0200:

 i = setgid(sStat.st_gid);
 i = i || setuid(sStat.st_uid);
 
 sure enough. It switches back to the owning user/group of the repo.
 
 IMO, that's not a bug, just an unfortunate side effect of your setup.

In fact, it's intended behavior when running as root:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01486.html

Andy
--
TAI64 timestamp: 40005387560c
___
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] question about parms and ownership of repo vs current/parent dir

[Stephan Beal]

On Thu, May 29, 2014 at 5:22 PM, Michai Ramakers m.ramak...@gmail.com
wrote:

 Does this also explain my last mail (in case one file is owned
 root.wheel, and the other file and parent-dir are owned ftp.ftp, all
 works fine)?


Yes - because the file is owned by root, the dropping of privileges is
actually a no-op, in that we're dropping back from root to root. At least
that's my understanding of the code.

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

Re: [fossil-users] question about parms and ownership of repo vs current/parent dir

[Andy Bradford]

Thus said Michai Ramakers on Thu, 29 May 2014 17:22:08 +0200:

 Alright, thanks for looking into this  (, all). Does this also explain
 my last mail (in case one file is owned root.wheel, and the other file
 and parent-dir are owned ftp.ftp, all works fine)?

I may have mispoken earlier. Fossil only does chroot and drop privileges
when  serving  files  (e.g.  fossil  server),  however,  the  email  you
originally sent  was simply a  ``fossil sync'' operation from  one local
file to  another. You also mentioned  that you became root  by doing su.
Perhaps there is something more in the way you are doing things that has
been missed.  Clearly there is a  permission problem, so maybe  my claim
that it was due to chroot/privilege dropping was premature.

This might require additional information/investigation.

Andy
--
TAI64 timestamp: 400053878bbd
___
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] Question on config syncing

[Andreas Kupries]

On Mon, Apr 28, 2014 at 6:55 PM, Andreas Kupries
andre...@activestate.com wrote:
 On Mon, Apr 28, 2014 at 5:27 PM, Richard Hipp d...@sqlite.org wrote:
 On Mon, Apr 28, 2014 at 8:23 PM, Richard Hipp d...@sqlite.org wrote:
 On Mon, Apr 28, 2014 at 5:09 PM, Andreas Kupries
 andre...@activestate.com wrote:

 and lots of users are _not_ shown, especially not the new mi entry.

 Fossil is running SELECT * FROM user WHERE mtime?1 on the server side,
 with ?1 bound to 0.  But many entries of the user table on the server have a
 value of NULL.


 I ran this:

 UPDATE user SET mtime=strfime('%s','now') WHERE mtime IS NULL;

 So I'm guessing the sync will work better now.

 Yes. I can confirm that my local copy now has all the users.
 Thank you.

 I still suspect that these entries with mtime IS NULL come from the
 self-registration.
 Any way to confirm|falsify this suspicion ?

Just came across

http://fossil-scm.org/index.html/info/a9235f4cc4af60970cfffa865ffe54452f49d811

which fixes the issue in fossil itself, confirming the suspicion.

Thank you.

Now we just need some way for the fossil executable to auto-fix a
repository when it sees this type of damage.

In the meantime I will go over the repositories on core and manually fix them.
Ok, done: Tk, Itcl, tclconfig, Thread; and Tcl again (had another new
self-registered user since yesterday). All others were good.

Will check them again in a few days ... You might wish to update the fossil exe



 --
 Andreas Kupries
 Senior Tcl Developer
 Code to Cloud: Smarter, Safer, Faster(tm)
 F: 778.786.1133
 andre...@activestate.com
 http://www.activestate.com
 Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

 EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
 http://www.tcl.tk/community/tcl2014/



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
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] Question on config syncing

[Stephan Beal]

On Tue, Apr 29, 2014 at 6:52 PM, Andreas Kupries
andre...@activestate.comwrote:

 Now we just need some way for the fossil executable to auto-fix a
 repository when it sees this type of damage.


Any objections to me adding this to the rebuild bits:

update user set mtime=strftime('%s','now') where mtime IS NULL

?

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

Re: [fossil-users] Question on config syncing

[Stephan Beal]

On Tue, Apr 29, 2014 at 6:54 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Apr 29, 2014 at 6:52 PM, Andreas Kupries andre...@activestate.com
  wrote:

 Now we just need some way for the fossil executable to auto-fix a
 repository when it sees this type of damage.


 Any objections to me adding this to the rebuild bits:


[stephan@host:~/cvs/fossil/fossil]$ f-query -e select login, mtime from
user limit 3
login mtime
stephan NULL
anonymous NULL
nobody NULL

[stephan@host:~/cvs/fossil/fossil]$ f rebuild
  100.0% complete...

[stephan@host:~/cvs/fossil/fossil]$ f-query -e update user set mtime=NULL
where login='anonymous'

[stephan@host:~/cvs/fossil/fossil]$ f-query -e select login, mtime from
user limit 3
login mtime
stephan 1398790645
anonymous NULL
nobody 1398790645

[stephan@host:~/cvs/fossil/fossil]$ f rebuild
  100.0% complete...

[stephan@host:~/cvs/fossil/fossil]$ f-query -e select login, mtime from
user limit 3
login mtime
stephan 1398790645
anonymous 1398790680
nobody 1398790645

@Andreas: would that suffice for your purposes?
@Richard: any objections?

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

Re: [fossil-users] Question on config syncing

[Andreas Kupries]

+1 from me.

Thinking of rebuilds, any chance of having the rebuild ignore tables
whose names starts with fx (case-insensitive) ?

I currently work on a tool which stores some of its data in the repo
db, in custom tables. A rebuild leaves these tables empty.



On Tue, Apr 29, 2014 at 9:54 AM, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Apr 29, 2014 at 6:52 PM, Andreas Kupries andre...@activestate.com
 wrote:

 Now we just need some way for the fossil executable to auto-fix a
 repository when it sees this type of damage.


 Any objections to me adding this to the rebuild bits:

 update user set mtime=strftime('%s','now') where mtime IS NULL

 ?

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




-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
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] Question on config syncing

[Andreas Kupries]

Yes, that looks good to me. Thank you.

On Tue, Apr 29, 2014 at 10:01 AM, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Apr 29, 2014 at 6:54 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Apr 29, 2014 at 6:52 PM, Andreas Kupries
 andre...@activestate.com wrote:

 Now we just need some way for the fossil executable to auto-fix a
 repository when it sees this type of damage.


 Any objections to me adding this to the rebuild bits:


 [stephan@host:~/cvs/fossil/fossil]$ f-query -e select login, mtime from
 user limit 3
 login mtime
 stephan NULL
 anonymous NULL
 nobody NULL

 [stephan@host:~/cvs/fossil/fossil]$ f rebuild
   100.0% complete...

 [stephan@host:~/cvs/fossil/fossil]$ f-query -e update user set mtime=NULL
 where login='anonymous'

 [stephan@host:~/cvs/fossil/fossil]$ f-query -e select login, mtime from
 user limit 3
 login mtime
 stephan 1398790645
 anonymous NULL
 nobody 1398790645

 [stephan@host:~/cvs/fossil/fossil]$ f rebuild
   100.0% complete...

 [stephan@host:~/cvs/fossil/fossil]$ f-query -e select login, mtime from
 user limit 3
 login mtime
 stephan 1398790645
 anonymous 1398790680
 nobody 1398790645

 @Andreas: would that suffice for your purposes?
 @Richard: any objections?

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




-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
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] Question on config syncing

[Stephan Beal]

On Tue, Apr 29, 2014 at 7:04 PM, Andreas Kupries
andre...@activestate.comwrote:

 +1 from me.


If i hear no veto from Richard this evening i'll check it in.


 Thinking of rebuilds, any chance of having the rebuild ignore tables
 whose names starts with fx (case-insensitive) ?


We added that late last Summer or Fall:

 [stephan@host:~/cvs/fossil/fossil/src]$ grep fx_ rebuild.c
AND name NOT GLOB 'fx_*'

I currently work on a tool which stores some of its data in the repo
 db, in custom tables. A rebuild leaves these tables empty.


That's why it was added, IIRC. And i wanted it for libfossil (but the fx
prefix came from you).

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

Re: [fossil-users] Question on config syncing

[Andreas Kupries]

On Tue, Apr 29, 2014 at 10:13 AM, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Apr 29, 2014 at 7:04 PM, Andreas Kupries andre...@activestate.com
 wrote:

 +1 from me.


 If i hear no veto from Richard this evening i'll check it in.


 Thinking of rebuilds, any chance of having the rebuild ignore tables
 whose names starts with fx (case-insensitive) ?


 We added that late last Summer or Fall:

  [stephan@host:~/cvs/fossil/fossil/src]$ grep fx_ rebuild.c
 AND name NOT GLOB 'fx_*'

 I currently work on a tool which stores some of its data in the repo
 db, in custom tables. A rebuild leaves these tables empty.

Ok. Then the issue was me using an old version of fossil (1.21 of 2011).
In the wake of the user/mtime issue I updated to the head,
self-compiled (*) to see if that was the issue. Which means that I
should be good on the rebuild front now as well.

I will check this evening.


(*) Can't actually use the downloads (My desktop/net box is a bit old,
and the glibc apparently too old for the current prebuilt binaries.).
No biggie. I have no trouble with building stuff myself, and fossil is
easy.



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
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] Question on config syncing

[Stephan Beal]

On Tue, Apr 29, 2014 at 7:44 PM, Andreas Kupries
andre...@activestate.comwrote:

 Ok. Then the issue was me using an old version of fossil (1.21 of 2011).
 In the wake of the user/mtime issue I updated to the head,
 self-compiled (*) to see if that was the issue. Which means that I
 should be good on the rebuild front now as well.


You weren't until ... right now. i just committed this:

Index: src/rebuild.c
==
--- src/rebuild.c
+++ src/rebuild.c
@@ -370,10 +370,13 @@
   WHERE rid IN (SELECT rid FROM shun JOIN blob USING(uuid))
   );
   db_multi_exec(
 DELETE FROM config WHERE name IN ('remote-code', 'remote-maxid')
   );
+  db_multi_exec(
+UPDATE user SET mtime=strftime('%%s','now') WHERE mtime IS NULL
+  )


 I will check this evening.


Please pull before doing so.


(*) Can't actually use the downloads (My desktop/net box is a bit old,
 and the glibc apparently too old for the current prebuilt binaries.).
 No biggie. I have no trouble with building stuff myself, and fossil is
 easy.


i only use the downloadable fossil binaries when i sorely break my local
sources and can't build.

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

Re: [fossil-users] Question on config syncing

[Andreas Kupries]

On Tue, Apr 29, 2014 at 11:03 AM, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Apr 29, 2014 at 7:44 PM, Andreas Kupries andre...@activestate.com
 wrote:

 Ok. Then the issue was me using an old version of fossil (1.21 of 2011).
 In the wake of the user/mtime issue I updated to the head,
 self-compiled (*) to see if that was the issue. Which means that I
 should be good on the rebuild front now as well.


 You weren't until ... right now. i just committed this:

Ok.

 I will check this evening.


 Please pull before doing so.

Will do. CC myself as proper reminder.

 (*) Can't actually use the downloads (My desktop/net box is a bit old,
 and the glibc apparently too old for the current prebuilt binaries.).
 No biggie. I have no trouble with building stuff myself, and fossil is
 easy.


 i only use the downloadable fossil binaries when i sorely break my local
 sources and can't build.

Heh. For that you keep an older working executable around, use it to
make a new checkout, go to the last working revision and build that
... Or something.




-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question on config syncing

[Andreas Kupries]

Logging in as admin to the Tcl repository and looking at the
user list, i.e.
http://core.tcl.tk/tcl/setup_ulist

I see an entry for 'mi', id 92.

Using 'fossil config pull all' on the repository into my local copy,
then rebuild'ing the local database,
I lastly look at the local user table
and lots of users are _not_ shown, especially not the new mi entry.

It seems to happen for the self-registered user entries.
Older entries of this type were apparently not pulled for my initial run either.

Any idea why these are not retrieved by the config pull ?


-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster(tm)
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
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] Question on config syncing

[Richard Hipp]

On Mon, Apr 28, 2014 at 5:09 PM, Andreas Kupries
andre...@activestate.comwrote:

 Logging in as admin to the Tcl repository and looking at the
 user list, i.e.
 http://core.tcl.tk/tcl/setup_ulist

 I see an entry for 'mi', id 92.

 Using 'fossil config pull all' on the repository into my local copy,
 then rebuild'ing the local database,
 I lastly look at the local user table
 and lots of users are _not_ shown, especially not the new mi entry.

 It seems to happen for the self-registered user entries.
 Older entries of this type were apparently not pulled for my initial run
 either.

 Any idea why these are not retrieved by the config pull ?


Fossil is running SELECT * FROM user WHERE mtime?1 on the server side,
with ?1 bound to 0.  But many entries of the user table on the server have
a value of NULL.


-- 
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] Question on config syncing

[Richard Hipp]

On Mon, Apr 28, 2014 at 8:23 PM, Richard Hipp d...@sqlite.org wrote:




 On Mon, Apr 28, 2014 at 5:09 PM, Andreas Kupries andre...@activestate.com
  wrote:

 Logging in as admin to the Tcl repository and looking at the
 user list, i.e.
 http://core.tcl.tk/tcl/setup_ulist

 I see an entry for 'mi', id 92.

 Using 'fossil config pull all' on the repository into my local copy,
 then rebuild'ing the local database,
 I lastly look at the local user table
 and lots of users are _not_ shown, especially not the new mi entry.

 It seems to happen for the self-registered user entries.
 Older entries of this type were apparently not pulled for my initial run
 either.

 Any idea why these are not retrieved by the config pull ?


 Fossil is running SELECT * FROM user WHERE mtime?1 on the server side,
 with ?1 bound to 0.  But many entries of the user table on the server have
 a value of NULL.


I ran this:

UPDATE user SET mtime=strfime('%s','now') WHERE mtime IS NULL;

So I'm guessing the sync will work better now.





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




-- 
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] Question on config syncing

[Andreas Kupries]

On Mon, Apr 28, 2014 at 5:27 PM, Richard Hipp d...@sqlite.org wrote:
 On Mon, Apr 28, 2014 at 8:23 PM, Richard Hipp d...@sqlite.org wrote:
 On Mon, Apr 28, 2014 at 5:09 PM, Andreas Kupries
 andre...@activestate.com wrote:

 and lots of users are _not_ shown, especially not the new mi entry.

 Fossil is running SELECT * FROM user WHERE mtime?1 on the server side,
 with ?1 bound to 0.  But many entries of the user table on the server have a
 value of NULL.


 I ran this:

 UPDATE user SET mtime=strfime('%s','now') WHERE mtime IS NULL;

 So I'm guessing the sync will work better now.

Yes. I can confirm that my local copy now has all the users.
Thank you.

I still suspect that these entries with mtime IS NULL come from the
self-registration.
Any way to confirm|falsify this suspicion ?

-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster(tm)
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question on repo size after repeated binary file commits?

[sky5walk]

I am curious what is stored in the repo for each new commit that includes a
tiny change to a binary file.
Whether a dll or an image file, is fossil storing each binary file
compressed, uncompressed or some sort of delta?
Over time(6mo's to 1yr), I would like to reduce my repo size by purging
really old binary files.

Thanks for fossil!
___
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] Question on repo size after repeated binary file commits?

[Mark Janssen]

On Sun, Dec 22, 2013 at 7:37 PM, sky5w...@gmail.com wrote:

 I am curious what is stored in the repo for each new commit that includes
 a tiny change to a binary file.
 Whether a dll or an image file, is fossil storing each binary file
 compressed, uncompressed or some sort of delta?
 Over time(6mo's to 1yr), I would like to reduce my repo size by purging
 really old binary files.

 Thanks for fossil!


Fossil does have delta encoding but I am not sure whether this is  used for
binary files. However part of the design philosophy of Fossil is that no
history is ever lost. So reducing the repository size is generally not
possible.

Mark
___
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] Question on repo size after repeated binary file commits?

[sky5walk]

Ah, is there a way to quantify the binary delta?
If I have a 1MB binary file and commit a 1 byte change, what is the size of
the computed binary delta?

You are correct of course, but I tend not to extend the spirit of fossil to
binary files and images. It is their existence and not legacy that is
critical in my application.

An example would be icons used for toolbars and menus. If I tweak them or
add layering, I sorta obsolete the originals. Here, I prefer the smaller
repo.


On Sun, Dec 22, 2013 at 1:46 PM, Mark Janssen mpc.jans...@gmail.com wrote:



 On Sun, Dec 22, 2013 at 7:37 PM, sky5w...@gmail.com wrote:

 I am curious what is stored in the repo for each new commit that includes
 a tiny change to a binary file.
  Whether a dll or an image file, is fossil storing each binary file
 compressed, uncompressed or some sort of delta?
 Over time(6mo's to 1yr), I would like to reduce my repo size by purging
 really old binary files.

 Thanks for fossil!


 Fossil does have delta encoding but I am not sure whether this is  used
 for binary files. However part of the design philosophy of Fossil is that
 no history is ever lost. So reducing the repository size is generally not
 possible.

 Mark

 ___
 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] Question on repo size after repeated binary file commits?

[Stephan Beal]

On Sun, Dec 22, 2013 at 8:44 PM, sky5w...@gmail.com wrote:

 Ah, is there a way to quantify the binary delta?
 If I have a 1MB binary file and commit a 1 byte change, what is the size
 of the computed binary delta?


Very, very small:

Create two binaries with a one-byte difference:

[stephan@host:~/cvs/fossil/libfossil]$ cat f-tag  foo; echo -n x  foo;
cat f-wiki  foo

[stephan@host:~/cvs/fossil/libfossil]$ cat f-tag  bar; echo -n y  bar;
cat f-wiki  bar


[stephan@host:~/cvs/fossil/libfossil]$ l foo bar
-rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 bar
-rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 foo

The delta:

[stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar
4tz2
2Qjj@0,1:yO@0,2UEw@2Qk7,3wep03;

Confirm that the delta actually does what's expected:

[stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar  baz
[stephan@host:~/cvs/fossil/libfossil]$ ./f-delta -a baz foo  bar2
[stephan@host:~/cvs/fossil/libfossil]$ cmp bar bar2
[stephan@host:~/cvs/fossil/libfossil]$ echo $?
0

To answer your question: 37 bytes:

[stephan@host:~/cvs/fossil/libfossil]$ l baz
-rw-rw-r-- 1 stephan users 37 Dec 22 20:49 baz

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

Re: [fossil-users] Question on repo size after repeated binary file commits?

[sky5walk]

Thanks. I didn't know how binary was handled given the Timeline diff
response = cannot compute difference between binary files.
I think it would be cool if instead fossil listed some of the metrics used
or determined in the binary delta operation.

Thanks for Fossil!


On Sun, Dec 22, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Sun, Dec 22, 2013 at 8:44 PM, sky5w...@gmail.com wrote:

 Ah, is there a way to quantify the binary delta?
 If I have a 1MB binary file and commit a 1 byte change, what is the size
 of the computed binary delta?


 Very, very small:

 Create two binaries with a one-byte difference:

 [stephan@host:~/cvs/fossil/libfossil]$ cat f-tag  foo; echo -n x  foo;
 cat f-wiki  foo

 [stephan@host:~/cvs/fossil/libfossil]$ cat f-tag  bar; echo -n y  bar;
 cat f-wiki  bar


 [stephan@host:~/cvs/fossil/libfossil]$ l foo bar
 -rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 bar
 -rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 foo

 The delta:

 [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar
 4tz2
 2Qjj@0,1:yO@0,2UEw@2Qk7,3wep03;

 Confirm that the delta actually does what's expected:

 [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar  baz
 [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta -a baz foo  bar2
 [stephan@host:~/cvs/fossil/libfossil]$ cmp bar bar2
 [stephan@host:~/cvs/fossil/libfossil]$ echo $?
 0

 To answer your question: 37 bytes:

 [stephan@host:~/cvs/fossil/libfossil]$ l baz
 -rw-rw-r-- 1 stephan users 37 Dec 22 20:49 baz

 --
 - 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] Question on repo size after repeated binary file commits?

[sky5walk]

Really, I am only implying some minimal file statistic like 'DeltaSize(%)'
or somesuch to show the user it is in fact compared internally. The current
message contradicts what is in fact happening. Maybe change that message to
Cannot visually display binary diffs. DeltaSize(%) = -10.


On Sun, Dec 22, 2013 at 3:15 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Sun, Dec 22, 2013 at 9:06 PM, sky5w...@gmail.com wrote:

 Thanks. I didn't know how binary was handled given the Timeline diff
 response = cannot compute difference between binary files.


 That message is a bit misleading. It really means a visual difference.
 There isn't a mechanism to show a textual diff for binaries, and fossil's
 internal deltas and its text diffs are two completely different beasts.


 I think it would be cool if instead fossil listed some of the metrics
 used or determined in the binary delta operation.


 The diff-related pages don't actually use the delta code (though
 diff/delta are logically similar, they are much different implementations).
 A delta blob does in fact know (without expensive processing) the size of
 the original blob and the size of the delta, so it might be feasible to do
 that. The unsightly part is that fossil doesn't really know what's a binary
 and what isn't (the delta algorithm is the same for all data). When
 performing a textual diff and it runs into any binary-looking data, it
 aborts the diff and assumes that it's binary. i.e. it would first need to
 run through the text diff and, as a fallback, generate statistics for a
 binary delta. Yeah, doable, but IMO horribly ugly because it would have to
 be done as a fallback for the diff generation, making it more expensive
 (computation/memory) than it really needs to be.

 --
 - 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] Question on repo size after repeated binary file commits?

[Stephan Beal]

On Sun, Dec 22, 2013 at 9:57 PM, sky5w...@gmail.com wrote:

 Really, I am only implying some minimal file statistic like 'DeltaSize(%)'
 or somesuch to show the user it is in fact compared internally. The current
 message contradicts what is in fact happening. Maybe change that message to
 Cannot visually display binary diffs. DeltaSize(%) = -10.


It is in principal an minimal change, but it is more invasive than it
sounds because the parts which deal with diffs are 100% different, and
separate from, those which deal with deltas. The code which generates the
diff, and outputs the cannot... message does not have enough info to know
about the underlying delta (nor whether there is in fact any delta at all -
there is not always one).

-- 
- 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] question about added, then deleted files and checkin

[Michai Ramakers]

Hello,

when I do this:

$ touch plop
$ fossil addremove
$ rm plop
$ fossil addremove

...I see in 'fossil status' and when doing 'fossil commit' one change,
namely the deleted file. When I commit, I see a resulting entry in the
webpage timeline with no changes.

What's the rationale for even mentioning the deleted file at all? Just
for my info.

Thanks,
Michai
___
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] question about added, then deleted files and checkin

[Richard Hipp]

On Mon, Oct 28, 2013 at 10:04 AM, Michai Ramakers m.ramak...@gmail.comwrote:

 Hello,

 when I do this:

 $ touch plop
 $ fossil addremove
 $ rm plop
 $ fossil addremove

 ...I see in 'fossil status' and when doing 'fossil commit' one change,
 namely the deleted file. When I commit, I see a resulting entry in the
 webpage timeline with no changes.

 What's the rationale for even mentioning the deleted file at all? Just
 for my info.


Probably (I'm guessing) what you are seeing is some kind of bug that
prevents an unmanaged file that was previous added by not yet committed
from being removed from the pending-commit list when it is subsequently
found by addremove to no longer exist.  Admit it:  this is a corner 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

Re: [fossil-users] question about added, then deleted files and checkin

[Michai Ramakers]

On 28 October 2013 15:10, Richard Hipp d...@sqlite.org wrote:

 What's the rationale for even mentioning the deleted file at all? Just
 for my info.

 Probably (I'm guessing) what you are seeing is some kind of bug that
 prevents an unmanaged file that was previous added by not yet committed from
 being removed from the pending-commit list when it is subsequently found by
 addremove to no longer exist.  Admit it:  this is a corner case.

That is true, I was just playing around really.

Thanks,
Michai
___
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] Question about Source forge Fossil hosting

[Jeff Rogers]

Jan Nijtmans wrote:

Jeff, this is a very useful recipe that should be documented in
the fossil documentation somewhere!

Tried it, and only found one obvious minor typo:
 ssh -t myproject,myu...@shell.sourceforge.net
mailto:myu...@shell.sourceforge.netmailto:myu...@shell.sourceforge.net
create
This should be:
 ssh -t myuser,myproj...@shell.sourceforge.net
mailto:myproj...@shell.sourceforge.netmailto:myu...@shell.sourceforge.net
create


Argh, I'm always making that mistake.  I have aliases I usually use for 
this, so I misremembered the longhand way.



A new fosclipse project is registered now, the related
chiselapp repositories moved there and all other steps
followed. So, I would expect the following url to lead to
the core repository:
http://fosclipse.sourceforge.net/projects/fosclipse/cgi-bin/repos/fosclipse-core
I tried all kinds of variations for this URL as well,
but I don't see anything. Any ideas how I can debug
that? What did I do wrong?


It depends on the files you created of course, but if you created the 
repository as /home/project-web/fosclipse/repos/fosclipse-core.fsl and 
the cgi script as /home/project-web/fosclipse/cgi-bin/fosclipse-core.fsl

then your url would be
http://fosclipse.sourceforge.net/cgi-bin/fosclipse-core.fsl

The projects/fosclipse part of the path is only when you're looking at 
sourceforge's own app (i.e., http://sourceforge.net/) - my recipe only 
works on the project web ( http://fosclipse.sourceforge.net/ )


It's also perhaps confusing that my recipe includes two very different 
files both named myproject.fsl - the actual repository AND the cgi 
wrapper.  It's also unnecessary to have them both named the same, and 
the setup differs from the fossil docs (which I should have checked first).


In any case, the first task for debugging is getting the cgi to run in 
the first place.  What did you name the wrapper script under your 
cgi-bin directory?


Once you're successfully hitting that, you should get some more 
informative errors from fossil about why it can't find your repository.


-J



Thanks!
 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] Question about Source forge Fossil hosting

[Martijn Coppoolse]

On 04/05/2013 09:12 AM, Jan Nijtmans wrote:
 Jeff, this is a very useful recipe that should be documented in
 the fossil documentation somewhere!
 
 Tried it, and only found one obvious minor typo:
ssh -t myproject,myu...@shell.sourceforge.net create
 This should be:
ssh -t myuser,myproj...@shell.sourceforge.net create
 
 A new fosclipse project is registered now, the related
 chiselapp repositories moved there and all other steps
 followed. So, I would expect the following url to lead to
 the core repository:
 http://fosclipse.sourceforge.net/projects/fosclipse/cgi-bin/repos/fosclipse-core
 I tried all kinds of variations for this URL as well,
 but I don't see anything. Any ideas how I can debug
 that? What did I do wrong?

I haven't really looked into it, but
  http://fosclipse.sourceforge.net/cgi-bin/
returns a 403 error (Forbidden), which suggests that there _is_ a
cgi-bin directory there all right, but that there's a permissions problem.

(I suspect the /projects/fosclipse/ part of your URL are just
server-side mapping for the 'fosclipse' subdomain).


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

[fossil-users] Question about Source forge Fossil hosting

[jim Schimpf]

Hi,

I have used Chiselapp for hosting some Fossil project but just got a 
note that he is shutting down May first.  So I decided to try the source forge 
version (http://fossilrepos.sourceforge.net/) .  Very easy to create a project 
but my previous experience with Chisel seems to not to apply as I was trying to 
push the repository there it just didn't work.  Has anyone else had success 
with this ?

--jim schimpf
___
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] Question about Source forge Fossil hosting

[Konstantin Khomoutov]

On Fri, 29 Mar 2013 09:10:48 -0400
jim Schimpf jim.schi...@gmail.com wrote:

   I have used Chiselapp for hosting some Fossil project but
 just got a note that he is shutting down May first.  So I decided to
 try the source forge version (http://fossilrepos.sourceforge.net/) .

I'd like to point out this is not at all a source forge version.
This is just a regular SF project created by someone -- see for
yourself [1].  To my knowledge, SF does not provide Fossil hosting.

By the way, my opinion on the matters is that ideally someone would
convince any of big players (like SF, advogato, bitbucket, berlios,
google code etc) to provide Fossil hosting as part of their existing
architecture.  Otherwise, I reckon, Fossil hosting will remain a niche
activity and will still have zero visibility as it has today.

1. http://sf.net/projects/fossilrepos
___
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] Question about Source forge Fossil hosting

[Jeff Rogers]

Konstantin Khomoutov wrote:

On Fri, 29 Mar 2013 09:10:48 -0400



I'd like to point out this is not at all a source forge version.
This is just a regular SF project created by someone -- see for
yourself [1].  To my knowledge, SF does not provide Fossil hosting.


SF doesn't provide it, but it's easy to do yourself.

Steps:
0. Create a SF account, SF project, and set up your ssh keys so that you 
can log into their shell service.


1. connect to the SF shell service, and navigate to the project web 
directory for your project:


$ ssh -t myproject,myu...@shell.sourceforge.net create

Welcome to sourceforge!
-bash-3.2$ cd /home/project-web/myproject

2. Obtain a fossil binary.  Unfortunately the ones from the download 
page on fossil-scm.org are built against a newer version of linux than 
SF's servers and so will not run there, but you can build a compatible 
older version yourself.  (Or some kind person could put of a fossil 
binary that will run on a 2.6.18 kernel).   Put that fossil binary in 
the project-web directory.


[get fossil somehow]
-bash-3.2$ ./fossil
Usage: ./fossil COMMAND ...
   or: ./fossil help   -- for a list of common commands
   or: ./fossil help COMMMAND  -- for help with the named command
-bash-3.2$

3. create a folder for your fossil repository that is writable by the 
web server.


-bash-3.2$ mkdir repo
-bash-3.2$ ls -ld repo
drwxrwx--x 2 myuser apache 4096 Mar 29 16:45 repo
-bash-3.2$

4. put your fossil repo in that directory, or create a new repo
-bash-3.2$ ../fossil new myproject.fsl
project-id: 1e70588abb440a6ff839f6897d5397107df3a044
server-id:  1962ad62f3e973014df28323a1c9f59c8b7f6f50
admin-user: myuser (initial password is 08324d)
-bash-3.2$

5. make the repository writable by the web server
-bash-3.2$ chmod g+w myproject.fsl
-bash-3.2$

6. create the cgi frontend
-bash-3.2$ cd /home/project-web/myproject/cgi-bin
-bash-3.2$ cat  myproject.fsl
#!/usr/bin/env /home/project-web/myproject/fossil
repository: /home/project-web/myproject/repo/myproject.fsl
^D
bash-3.2$ chmod +x myproject.fsl

7. connect to your new fossil repository

http://myproject.sourceforge.net/cgi-bin/myproject.fsl

8. do normal fossil setup tasks - set project name, design, etc.

SF has a policy that you should include the sourceforge logo on your 
project-web hosted pages, so go to your sourceforge project page, select 
project admin  analytics, and go to the Displaying the sourceforge.net 
logo page;  pick the appropriate logo and change the fossil logo in the 
header setup admin page from


  div class=logo
img src=$baseurl/logo alt=logo
brnobr$project_name/nobr
  /div

to

div class=logo
a href=http://sourceforge.net/projects/myptoject;img 
src=http://sflogo.sourceforge.net/sflogo.php?group_id=12345678amp;type=16; 
width=150 height=40 border=0 //a

brnobr$project_name/nobr
  /div

(for whichever logo you happened to choose)

9. Set up your project web homepage to point to your fossil repo.

-bash-3.2$ cd /home/project-web/myproject/htdocs
-bash-3.2$ cat  index.php
?php header(Location: 
http://myproject.sourceforge.net/cgi-bin/myproject.fsl/home;) ?

^D
-bash-3.2$

10. clone your fossil repository from elsewhere, make changes, etc.

$ fossil clone http://myproject.sourceforge.net/cgi-bin/myproject.fsl 
myproject.fsl




By the way, my opinion on the matters is that ideally someone would
convince any of big players (like SF, advogato, bitbucket, berlios,
google code etc) to provide Fossil hosting as part of their existing
architecture.  Otherwise, I reckon, Fossil hosting will remain a niche
activity and will still have zero visibility as it has today.


You could try upvoting this ideatorrent post:
https://sourceforge.net/apps/ideatorrent/sourceforge/ideatorrent/idea/603/

But I'm they don't use it any more, and feature requests are just done 
through their forge project:

https://sourceforge.net/p/forge/feature-requests/

-J




___
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] Question about tags and autosync...

[Lluís Batlle i Rossell]

On Wed, Apr 25, 2012 at 07:00:08PM -0700, Matt Welland wrote:
 On Wed, Apr 25, 2012 at 6:49 PM, Richard Hipp d...@sqlite.org wrote:
 
 
 
  On Wed, Apr 25, 2012 at 6:51 PM, Michael L. Barrow 
  mlbar...@barrow.mewrote:
 
  Firstly, I'm running:
 This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC
 
  Perhaps I'm confused, but the documentation for autosync being enabled
  says:
 
autosync If enabled, automatically pull prior to commit
 or update and automatically push after commit or
 tag or branch creation.  If the value is pullonly
 then only pull operations occur automatically.
 
  But, when I create a tag, it doesn't get pushed to the remote repo until
  I push or sync. Am I confused? Does it matter that this is a branch?
 
 
  What command did you use to create the tag?
 
  I don't see any code associated with the tag command that will do an
  autosync.  My suspicious is that the documentation you site above is
  incorrect and that tag creation should be removed from the list of things
  that will trigger an automatic push.
 
 
 I'd like it if a tag *did* an autosync. Have the pros 'n cons been
 discussed before?

I'm for it. I'd also like an autosync before 'merge'.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Question about tags and autosync...

[Michael L. Barrow]

Firstly, I'm running:
This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC

Perhaps I'm confused, but the documentation for autosync being enabled says:

   autosync If enabled, automatically pull prior to commit
or update and automatically push after commit or
tag or branch creation.  If the value is pullonly
then only pull operations occur automatically.

But, when I create a tag, it doesn't get pushed to the remote repo until 
I push or sync. Am I confused? Does it matter that this is a branch?


--
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249

___
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] Question about tags and autosync...

[Richard Hipp]

On Wed, Apr 25, 2012 at 6:51 PM, Michael L. Barrow mlbar...@barrow.mewrote:

 Firstly, I'm running:
This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC

 Perhaps I'm confused, but the documentation for autosync being enabled
 says:

   autosync If enabled, automatically pull prior to commit
or update and automatically push after commit or
tag or branch creation.  If the value is pullonly
then only pull operations occur automatically.

 But, when I create a tag, it doesn't get pushed to the remote repo until I
 push or sync. Am I confused? Does it matter that this is a branch?


What command did you use to create the tag?

I don't see any code associated with the tag command that will do an
autosync.  My suspicious is that the documentation you site above is
incorrect and that tag creation should be removed from the list of things
that will trigger an automatic push.




 --
 Michael Barrow
 michael at barrow dot me
 +1 (408) 782-4249

 __**_
 fossil-users mailing list
 fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about tags and autosync...

[Matt Welland]

On Wed, Apr 25, 2012 at 6:49 PM, Richard Hipp d...@sqlite.org wrote:



 On Wed, Apr 25, 2012 at 6:51 PM, Michael L. Barrow mlbar...@barrow.mewrote:

 Firstly, I'm running:
This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC

 Perhaps I'm confused, but the documentation for autosync being enabled
 says:

   autosync If enabled, automatically pull prior to commit
or update and automatically push after commit or
tag or branch creation.  If the value is pullonly
then only pull operations occur automatically.

 But, when I create a tag, it doesn't get pushed to the remote repo until
 I push or sync. Am I confused? Does it matter that this is a branch?


 What command did you use to create the tag?

 I don't see any code associated with the tag command that will do an
 autosync.  My suspicious is that the documentation you site above is
 incorrect and that tag creation should be removed from the list of things
 that will trigger an automatic push.


I'd like it if a tag *did* an autosync. Have the pros 'n cons been
discussed before?






 --
 Michael Barrow
 michael at barrow dot me
 +1 (408) 782-4249

 __**_
 fossil-users mailing list
 fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**
 fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




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

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


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

Re: [fossil-users] Question about tags and autosync...

[Michael L. Barrow]

On 4/25/12 6:49 PM, Richard Hipp wrote:


What command did you use to create the tag?


fossil tag add foo current
I don't see any code associated with the tag command that will do an 
autosync.  My suspicious is that the documentation you site above is 
incorrect and that tag creation should be removed from the list of 
things that will trigger an automatic push.




WHAT!?!?! Are you saying the docs don't match the source!? :-)


--
michael at barrow dot me
+1.408.782.4249

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

[fossil-users] question about makemake.tcl and non-Unix platforms

[Stephan Beal]

Hi, all,

i've added a couple files to my local json fork of fossil and i've got a
question: the new files are in makemake.tcl, and they're built fine for
Make-based builds on Unix, but is there anything special i need to be doing
to get them added to the Windows/etc builds?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] question

[Bill Burdick]

On Thu, Jul 21, 2011 at 4:23 AM, Rene renew...@xs4all.nl wrote:

 On Wed, 20 Jul 2011 20:10:45 -0400, Richard Hipp wrote:
  On Wed, Jul 20, 2011 at 5:15 PM, Zhang, Jenny  wrote:
 
  HI,
 
 
 
  I WOULD LIKE TO KNOW IF FOSSIL CAN HANDEL VERSION CONTROL FOR
  BINARY FILES?
 
  Yes.  For example I store all of my presentation slides (odp files
  generated by open office) in a Fossil repository.  There are also
  some binary files in the Fossil's self-hosting repository.  For
  example, the Fossil logo (a gif image) is stored in the repo:
  http://www.fossil-scm.org/fossil/artifact/0fa38d60655 [3]
 OK it stores binary files. does  it make deltas of  the versions or
 is every binary file just stored as is?


Here's the page on Fossil's delta format:
http://www.fossil-scm.org/index.html/doc/trunk/www/delta_format.wiki  It
looks similar to xdelta.


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

[fossil-users] Question on short-lived branches in fossil

[Steve Bennett]

So I created the 'autosetup' branch and added a commit which drh then merged to 
trunk.

Is that branch now defunct? If I want to propose some more, related changes,
do I create a new branch, say autosetup2, or do I continue or resurrect the 
autosetup branch?
If so, how?

Thanks,
Steve
 
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au   F: +61 7 3391 6002





___
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] Question on short-lived branches in fossil

[Richard Hipp]

On Fri, Jul 22, 2011 at 7:57 AM, Steve Bennett ste...@workware.net.auwrote:

 So I created the 'autosetup' branch and added a commit which drh then
 merged to trunk.

 Is that branch now defunct? If I want to propose some more, related
 changes,
 do I create a new branch, say autosetup2, or do I continue or resurrect the
 autosetup branch?
 If so, how?

 Just keep adding to the current branch.  Or create a new branch with the
same name, autosetup.

Fossil allows multiple short-lived branches with the same name.  We use
experimental a lot.  See, for example:

http://www.sqlite.org/src/timeline?n=400r=experimental
http://www.fossil-scm.org/fossil/timeline?n=200r=experimental

To continue using the existing autosetup branch, do this:

fossil update autosetup
# implement and test your changes
fossil commit

To start from trunk and create a new autosetup branch, do this:

fossil update trunk
# implement and test your changes
fossil commit --branch autosetup --bgcolor '#91d680'

The --bgcolor on the last commit is optional.  But it is nice to have color
on branches.  If you forget it, it can be added later using the Edit feature
of the UI.  (That's how I added color to your original autosetup branch).

Note that it is NOT necessary, nor even desirable, to create a branch before
you start adding changes to the branch.  You can create the branch when you
do the check in.  Or, using the Edit button in the UI, you can move a
check-in to a different branch after the fact.





 Thanks,
 Steve

 --
 µWeb: Embedded Web Framework - http://uweb.workware.net.au/
 WorkWare Systems Pty Ltd
 W: www.workware.net.au  P: +61 434 921 300
 E: ste...@workware.net.au   F: +61 7 3391 6002





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




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question on short-lived branches in fossil

[Remigiusz Modrzejewski]

On Jul 22, 2011, at 13:57 , Steve Bennett wrote:

 So I created the 'autosetup' branch and added a commit which drh then merged 
 to trunk.
 
 Is that branch now defunct?

If your changes are well integrated into trunk, and you're not continuing 
development in isolation from trunk, you should close your leaf. This way 
nobody will get confused and start working from that point.

 If I want to propose some more, related changes,
 do I create a new branch, say autosetup2, or do I continue or resurrect the 
 autosetup branch?
 If so, how?

In Fossil you don't actually close branches. You close commits. Branches are 
nothing more than a (propagating) tag. You can create a new commit  at any 
point and name it autosetup, this will render the autosetup branch open, as 
long as there is am open leaf with that tag. See an example here:
http://maxnet.org.pl/~lrem/fossil-branching
This is an example repository (60KB) showing a simple scenario with branching, 
merging, closing and resurrecting.


Kind regards,
Remigiusz Modrzejewski



___
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] Question on short-lived branches in fossil

[Remigiusz Modrzejewski]

On Jul 22, 2011, at 14:46 , Richard Hipp wrote:

fossil commit --branch autosetup --bgcolor '#91d680'
 
 The --bgcolor on the last commit is optional.  But it is nice to have color
 on branches.  If you forget it, it can be added later using the Edit feature
 of the UI.  (That's how I added color to your original autosetup branch).

By the way: this is one of the more cumbersome things about the UI. I'd really 
like to see this done automatically. But then again, I don't feel like wasting 
my time on this, so I don't expect anyone to waste theirs... 


Kind regards,
Remigiusz Modrzejewski



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