[fossil-users] fossil all ignore and case insensitive paths

[Ross Berteig]

We just happened to notice today that the list of repositories 
maintained for the use of "fossil all" is (naturally) stored with 
exactly the case that was used when each repository was mentioned to fossil.


Several folder names happened to be stored with different case than they 
actually have in the file system. All was well with most commands since 
Windows is a case-preserving but case-insensitive place. But


   c:...> fossil all ignore some.fossil

didn't actually ignore it when done from that folder. Adding --dry-run 
and comparing to the output of "fossil all list" revealed the different 
case, and --dry-run shows that the problem is that SQLite's GLOB 
operator is case sensitive:


  DELETE FROM global_config
WHERE name GLOB 'repo:K:/Some/MixedCase/PATH/some.fossil'

Should fossil all ignore respect the case-sensitive setting (or the 
mounted file system's capabilities, or the OS defaults, or) and try 
to match names insensitively when appropriate for the context?


Or is that actually as large a can or worms as it sounds as I type this 
question?


It seems like adding "COLLATE NOCASE" after the WHERE clause might do 
the trick. But the difficulty is likely deciding when to add it. And 
then hoping no one needed proper handling of cases for anything other 
than 7-bit ASCII letters.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

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

Re: [fossil-users] fossil all remove?

[Andy Bradford]

Thus said Richard Hipp on Fri, 19 Feb 2016 19:51:25 -0500:

> Again, I think the cleanup should be automatic.

It is for  the most part automatic. It isn't  automatic if the directory
still exists  but is no longer  a checkout. For example,  I accidentally
opened up a repository in /tmp  one time and apparently never closed it.
The repository  is long since gone,  but fossil continues to  hold on to
/tmp/:

$ fossil all ls -c | grep '^/tmp'
/tmp/
$ fossil all ignore -c /tmp/ 
$ fossil all ls -c | grep '^/tmp'
/tmp/

This  failed because  when the  ckout  is written  to the  global_config
table, it is stored with the trailing slash (derived from g.zLocalRoot).
But there  is no g.zLocalRoot  to use when  using ``fossil all''  so the
slash needs to be put back on.

This now works with:

http://www.fossil-scm.org/index.html/info/f7a5e10ce9337280

$ /tmp/fossil all ignore -c /tmp/
$ /tmp/fossil all ls -c | grep '^/tmp'
$ 

I wonder though, should fossil just automatically check for the presence
of the  local repository  and not just  the directory  and automatically
remove the ckout if there is no local repository in the directory?

Thanks,

Andy
-- 
TAI64 timestamp: 400056c8d3cd


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

Re: [fossil-users] fossil all remove?

[Ross Berteig]

On 2/19/2016 4:51 PM, Richard Hipp wrote:

On 2/19/16, Warren Young  wrote:
Again, I think the cleanup should be automatic.  But if you are still
having trouble the "fossil all ignore DIRECTORY" command should
manually remove the offending check-out from the list.  Maybe the "-c"
option is also needed - unclear.


This reminded me to look, and my recent obsession with the test suite 
has littered my fossil all list output with all the places I ran the 
tests. Which leads to two observations:


1. I thought I saw code in tester.tcl to prevent that... either I was 
misreading, or it doesn't work for me on Windows. Both are likely. I'll 
take a look at that "real soon now".


2. fossil all ignore only works for precisely named repositories, or 
with the -c option for named directories that are open workspaces. It 
would be nice if a path prefix could be used. Specifically, I was hoping 
that


C:> fossil all ignore C:\Users\Ross\Tmp\fbuild

would ignore the dozen repositories (and checkouts if repeated with -c) 
located below that path, since that folder is an out-of-tree build of 
fossil where I ran the test suite. I have several more folders just like 
it (built with different configurations).


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

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

Re: [fossil-users] fossil all remove?

[Richard Hipp]

On 2/19/16, Warren Young  wrote:
> On Feb 19, 2016, at 3:06 AM, Tino Lange 
> wrote:
>>
>> How can I get rid of an entry in "fossil all ls -c" for which the
>> checkout does not exist anymore? Do I need to fiddle with SQL?
>
> I think this happens when you nuke a fossil checkout (e.g. via rm -rf)
> without saying “fossil close” first.
>
> It used to happen to me with temporary and test repo checkouts until I got
> into the habit of saying “fossil close” on them before nuking them.

Again, I think the cleanup should be automatic.  But if you are still
having trouble the "fossil all ignore DIRECTORY" command should
manually remove the offending check-out from the list.  Maybe the "-c"
option is also needed - unclear.

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

Re: [fossil-users] fossil all remove?

[Warren Young]

On Feb 19, 2016, at 3:06 AM, Tino Lange  wrote:
> 
> How can I get rid of an entry in "fossil all ls -c" for which the 
> checkout does not exist anymore? Do I need to fiddle with SQL?

I think this happens when you nuke a fossil checkout (e.g. via rm -rf) without 
saying “fossil close” first.

It used to happen to me with temporary and test repo checkouts until I got into 
the habit of saying “fossil close” on them before nuking them.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil all remove?

[Tino Lange]

> Should be automatic.  When you do "fossil all ls -c", Fossil checks that
> each of the check-out directories exists, and removes any that do not
> exist from the list.

Thanks. The directory still exists (but with some other content now, 
especially it has no .fslckout file)

So I'll move it away, do a "fossil all ls -c" and move it afterwards back 
to its location :-)

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

Re: [fossil-users] fossil all remove?

[Stephan Beal]

On Fri, Feb 19, 2016 at 11:06 AM, Tino Lange  wrote:

> Hi Fossilers,
>
> There is no "fossil all remove".
> How can I get rid of an entry in "fossil all ls -c" for which the
> checkout does not exist anymore? Do I need to fiddle with SQL?
>

Fossil all recognizes when it sees a non-existing checkout and removes it
from its list. Or it did the last time i looked at that code. (Or that's
how i remember it, anyway!)

  /* If any repositories whose names appear in the ~/.fossil file could not
  ** be found, remove those names from the ~/.fossil file.
  */
  if( nToDel>0 ){
const char *zSql = "DELETE FROM global_config WHERE name IN toDel";
if( dryRunFlag ){
  fossil_print("%s\n", zSql);
}else{
  db_multi_exec("%s", zSql /*safe-for-%s*/ );
}
  }


-- 
- 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] fossil all remove?

[Richard Hipp]

On 2/19/16, Tino Lange  wrote:
> Hi Fossilers,
>
> There is no "fossil all remove".
> How can I get rid of an entry in "fossil all ls -c" for which the
> checkout does not exist anymore? Do I need to fiddle with SQL?
>

Should be automatic.  When you do "fossil all ls -c", Fossil checks
that each of the check-out directories exists, and removes any that do
not exist from the list.

Note that it only checks for the existence of the named directories.
It does not try to verify that each directory is in fact a valid
checkout.

-- 
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] fossil all remove?

[Tino Lange]

Hi Fossilers,

There is no "fossil all remove".
How can I get rid of an entry in "fossil all ls -c" for which the 
checkout does not exist anymore? Do I need to fiddle with SQL?

Thanks

Tino

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

Re: [fossil-users] fossil all rebuild: “not a valid repository”

[Scott Robison]

On Sat, Aug 1, 2015 at 4:36 AM, Gour g...@atmarama.net wrote:

 Hello,

 I had some recent changes of my OS-es (different distros, Linux, BSD…)
 and now after settling on Debian (testing) I’d like to rebuild all my
 Fossil repos, but encountered strange error:

 gour@atmarama ~/r/e/fossil fossil rebuild
   100.0% complete...
 gour@atmarama ~/r/e/fossil pwd
 /home/gour/repos/external/fossil
 gour@atmarama ~/r/e/fossil fossil all rebuild
 fossil rebuild /home/gour/repos/external/fossil
 Fossil internal error: not a valid repository:
 /home/gour/repos/external/fossil

 Any hint?


I'm doing some guess work here, but if the working directory is
/home/gour/repos/external/fossil then it can't be a valid repository. The
fossil all rebuild command wants to rebuild all the repositories that
fossil is aware of. It seems that somewhere along the
way /home/gour/repos/external/fossil changed from being a repository to a
directory?

Try fossil all list to generate a list of all the known repositories and
make sure they are indeed valid repositories. You can use fossil all ignore
to remove any that are no longer valid (or fossil all add as needed).

And if I guessed wrong, answering the wrong question, or am telling you
stuff you already know, my apologies.

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

Re: [fossil-users] fossil all rebuild: “not a valid repository”

[Gour]

Scott Robison sc...@casaderobison.com
writes:

 I'm doing some guess work here, but if the working directory is
 /home/gour/repos/external/fossil then it can't be a valid repository.

Yes.

 It seems that somewhere along the way /home/gour/repos/external/fossil
 changed from being a repository to a directory?

 Try fossil all list to generate a list of all the known repositories
 and make sure they are indeed valid repositories.

That explains things:

/home/gour/repos/external/fossil
/home/gour/repos/external/fossil.fossil
[…]

 You can use fossil all ignore to remove any that are no longer valid
 (or fossil all add as needed).

Thank you - this falls into the category of “what I learnt today”!!

 And if I guessed wrong, answering the wrong question, or am telling you
 stuff you already know, my apologies.

No, just the opposite!! Thank you.


Sincerely,
Gour

-- 
A person is said to be elevated in yoga when, having renounced 
all material desires, he neither acts for sense gratification 
nor engages in fruitive activities.


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

Re: [fossil-users] FOSSIL ALL

[tonyp]

I tried it and it works very well.  Thanks.  So, I guess I can leave all repos 
open all the time at both locations, and only do PULL/SYNC/PUSH at start/end of 
work day.
(I only worry a bit about the possibility of the USB eventually becoming full 
during a ‘push’ what consequences will it have on my repo’s integrity – a 
scenario less likely to happen on a server)

BTW, the syntax for Win7 is file://d:/path/file.fossil

Hmm, now I wonder, could this file syncing also work with FTP over the Internet 
by changing file: to ftp: (or something) as I have a private FTP server on all 
the time (you know, those NAS/storage servers)?

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



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


  I use mostly Windows, but every so often I open the repo on a Linux box (but 
I can do without Linux for now).  


Most thing we get working on Linux first, as that is the primary desktop for 
most of the Fossil developers (Jan excepted)


That said, I think the previously described system of syncing to your 
thumb-drive using the file: scheme is probably going to work best for you.  To 
recap:


(1) Run fossil all setting autosync off.

(2) Make copies of all repos onto your thumb drive.

(3) For each working check-out:

(3a) fossil remote file:/path/to/repo/on/thumb/drive


The above is a one-time setup.  Now, to transfer, just plug in your thumb drive 
and do:


 fossil all sync


Then take the thumb drive home and do fossil all sync there too (having 
previously done the same 3-step setup).


I'm not exactly sure what the syntax for the the file: URL is for the D: or 
E: filesystem (or whatever your USB stick comes up as).  And I'm away from the 
office and don't have access to a  windows machine to test it.  Some 
experimentation is in order, but once you get it working, it should just work.


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



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

[fossil-users] FOSSIL ALL

[Tony Papadimitriou]

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

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

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

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

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

Re: [fossil-users] FOSSIL ALL

[Richard Hipp]

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

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


Close them?  Why do you want to do that?

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

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

The scenario above is exactly why I invented fossil all.  :-)
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL ALL

[Tony Papadimitriou]

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

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

From: Stephan Beal 


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

Re: [fossil-users] FOSSIL ALL

[Tony Papadimitriou]

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

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

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

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

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

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

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



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

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


Close them?  Why do you want to do that?

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


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


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

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



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

Re: [fossil-users] FOSSIL ALL

[Tony Papadimitriou]

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

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

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

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

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

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

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

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

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



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

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


Close them?  Why do you want to do that?

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


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


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

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



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




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

Re: [fossil-users] FOSSIL ALL

[Stephan Beal]

On Mon, Oct 27, 2014 at 12:48 PM, Tony Papadimitriou to...@acm.org wrote:

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


All close does is:

a) removes the .fslckout resp. _FOSSIL_ file from the checkout
b) it should (IMO, if it doesn't already) remove the checkout from the
all list (kept in the global config db).

Thinking over it now, i confused repos and checkouts with regard to the
all list - when closing a checkout, the _checkout_, not the repo, should
(IMO) be removed from the all list.

Primarily 'close' is only used to remove the fossil crud from the tree
(the checkout db file), e.g. before ZIPping it up for distribution by a
client (but fossil supports zip/tar out of the box, so 'close' has even
fewer real uses).



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


If you are working by manually copying the repo dbs, then close is
probably a good thing to do, to avoid any side effects with blob IDs being
different between your checkout copies.

That's an unusual use case for Fossil, though - most users have a central
copy, either available via CGI, on a network drive, or similar (that said:
network drives are not recommended for this purpose - there are
historically many problems involving file locking over network shares).

If you have the option to host CGI scripts, i can strongly recommend moving
the repo to your CGI hoster and accessing it over the network. Most
internet providers offer CGI script support in their package, so if you
have a hoster already then you likely have this option.


So, are you saying, that if I keep both repo versions (work and home) open
 all the time, and simply copy over (from the backup) the related fossil
 files, there won’t be any corruption on either site?


Better not do that. If you really are copying around the repo dbs, it's
safest (IMO) to close them before copying them around. Not strictly
required, but not a bad idea.

And, I suppose instead of open (at the start of the day), I should be doing
 what exactly?  FOSSIL REV to update the current checkout from the just
 updated FOSSIL file which would appear like a revert on the other side?


In the normal case you'd do:

fossil update

But in your case i think that 'open' is the right approach (for a given
definition of right ;).



 Or, an UPDATE?  And, what if I’m on different branches?  Is this
 guaranteed to work correctly without creating any unpleasant side effects,
 from simple forks, etc., to the most serious of which would be a corruption
 of the repo and loss of work (and not only one day’s)?


fossil update BRANCH

will merge as appropriate. Using open/close, i believe you are far more at
risk for data loss than you would be using 'update.'


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


i would argue that that's not a use case fossil targets (or not a common
setup).



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

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



If you _must_ copy the repo files around, then the above loop is
essentially the right way to do it (again, for a given definition of
right ;).


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

[Richard Hipp]

On Mon, Oct 27, 2014 at 8:30 AM, Stephan Beal sgb...@googlemail.com wrote:



 If you are working by manually copying the repo dbs, then close is
 probably a good thing to do, to avoid any side effects with blob IDs being
 different between your checkout copies.


Yikes.  I forgot about that.  Stephan is right.

On the other hand, if both copied repos sprang from the same origin and
have always been copied and there the blob IDs will continue to be the same.

Even so, using the clone to file: technique is probably much safer.


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

Re: [fossil-users] FOSSIL ALL

[Richard Hipp]

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

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




Thinking about how to make this operation easier

Are you using Linux, Mac, or Windows?


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

Re: [fossil-users] FOSSIL ALL

[Sean Woods]

On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou to...@acm.org
wrote:
 I have several repos open at the same time, not always the same ones.  Before 
 I swap computers (home = work) I would like to close all open repos on one 
 site, and take a backup to take to the other site. 

I wanted to add my two cents here because this is very similar to my
current workflow.

I'm currently in a Windows environment and don't have access to a
server.  Though I use fossil, I basically only use it in one repository.

I have `c:\spw\fossils\projectname.fossil` that holds the main
repository.

Then I have a checkout in `c:\spw\code`

I work in code, then `fossil commit` to send my changes to fossils.

Problem, obviously, is that if this drive fails I'm totally hosed.  So
what I do is copy the repo from fossils to H:\ for backup purposes.  H:\
is a network drive that contains my home folder on Windows.

Periodically I use the copy command to copy the fossils repo over to
H:\.  This seems fine although I always get nervous I'll accidentally
switch the arguments around or somehow otherwise delete the main repo.

I would really like the option to autosync to another directory rather
than a remote system.  However, based on the sync documentation on the
fossil web site, it seems since sync is HTTP based, so HTTP'ing to
another dir is probably not an option.

I suppose I could `fossil ui` or `fossil serve` from a checkout in the
other repository and use sync that way, but there are lots of steps
there.

Also I saw in another thread the presence of a file:// URL scheme, but
saw no mention of it in the sync documentation.  If it does exist
perhaps it's a solution for me.

Is this related to what Tony P. is saying or am I completely in left
field?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL ALL

[Richard Hipp]

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


 I use mostly Windows, but every so often I open the repo on a Linux box
 (but I can do without Linux for now).


Most thing we get working on Linux first, as that is the primary desktop
for most of the Fossil developers (Jan excepted)

That said, I think the previously described system of syncing to your
thumb-drive using the file: scheme is probably going to work best for you.
To recap:

(1) Run fossil all setting autosync off.
(2) Make copies of all repos onto your thumb drive.
(3) For each working check-out:
(3a) fossil remote file:/path/to/repo/on/thumb/drive

The above is a one-time setup.  Now, to transfer, just plug in your thumb
drive and do:

 fossil all sync

Then take the thumb drive home and do fossil all sync there too (having
previously done the same 3-step setup).

I'm not exactly sure what the syntax for the the file: URL is for the D:
or E: filesystem (or whatever your USB stick comes up as).  And I'm away
from the office and don't have access to a  windows machine to test it.
Some experimentation is in order, but once you get it working, it should
just work.

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

Re: [fossil-users] FOSSIL ALL

[Richard Hipp]

On Mon, Oct 27, 2014 at 9:38 AM, Sean Woods s...@seanwoods.com wrote:



 Also I saw in another thread the presence of a file:// URL scheme, but
 saw no mention of it in the sync documentation.  If it does exist
 perhaps it's a solution for me.


I think it works.  But to be clear, I don't use it myself so maybe it is
busted without my knowledge.  Give it a try.  Report back if you 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

Re: [fossil-users] FOSSIL ALL

[Andy Bradford]

Thus said Tony Papadimitriou on Mon, 27 Oct 2014 14:18:04 +0200:

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

From ``fossil help sync'':

Use  the --private  option  to sync  private  branches with  the
remote repository.

Andy
--
TAI64 timestamp: 4000544e69f0
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL ALL

[Tomek Kott]

 Message: 7
 Date: 27 Oct 2014 09:50:39 -0600
 From: Andy Bradford amb-fos...@bradfords.org
 To: Tony Papadimitriou to...@acm.org
 Cc: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org
 Subject: Re: [fossil-users] FOSSIL ALL
 Message-ID: 20141027095039.14517.qm...@angmar.bradfordfamily.org
 
 Thus said Tony Papadimitriou on Mon, 27 Oct 2014 14:18:04 +0200:
 
  I guess the same scenario would be  valid if one used a server but had
  private branches.  My understanding  is that  private branches  do not
  sync so the only way to move  to another location is to move the whole
  fossil file. Correct?
 
 From ``fossil help sync'':
 
 Use  the --private  option  to sync  private  branches with  the
 remote repository.
 
 Andy
 --
 TAI64 timestamp: 4000544e69f0
 
 

FWIW, I work mostly on windows. I'm pretty confident I have never explicitly 
used file://. I just say 

fossil clone U:/fossils/myfossil.fossil

And fossil does the rest to put things in. Same for fossil remoteurl. I've 
used both relative and absolute paths to the fossil repo. Fossil automatically 
adds the file:// part as necessary. 

The way Richard described it will (should) work. 

As another FWIW, I have many repos on a network drive in '--wal' mode to share 
between windows / linux sources and have yet to have a corruption issue after a 
year and a half of not-so-frequent use. 

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

[fossil-users] [fossil all close]

[Andy Goth]

It occurred to me that a good exercise for reacquainting myself with the 
Fossil source tree (it's been awhile since DRH's presentation on same) 
would be to add a [fossil all close] command.  Plus I actually could use 
such a thing right about now since I'm reorganizing repositories and 
checkouts, and that requires a lot of closing.


[fossil all close] is there in my checkout, and it works, but I'm not 
satisfied until it's polished, and that means error messages being useful.


For example, saying current directory is not within an open checkout 
is most unhelpful when there's no indication which directory mistakenly 
found its way into [fossil all ls -c].


My design approach was simply to add close --chdir with useCheckouts 
and quiet to all_cmd, but this leads to confusing errors whenever 
anything is shy of perfect.


I suppose I could ditch quiet, but I thought I might try improving 
close_cmd to say which checkout it's talking about.  However, I did not 
want to break compatibility by changing the format of warning and error 
messages for modes of operation currently in use.


So I figured I'd make it explicitly name the checkout whenever --chdir 
is in use.  (Also silently ignore the not an open checkout error.) 
Just call find_option(chdir), right?  Wrong.  main() already snarfed 
it up, and find_option() has the lovely side effect of calling 
remove_from_argv() upon match.


Could add global variables, or could add a --header option or --verbose 
or whatever, but none of these approaches appeal to me since they are 
simply workarounds for a design limitation elsewhere.


The goal isn't to bang something out quickly, it's to explore the code, 
so please bear with me as I obsess over normally unimportant details.


Not sure if I'm actually asking anything.  I'm just putting out some 
thoughts and impressions.  Perhaps someone will have a suggestion.  Or I 
could indeed turn off quiet mode and leave close_cmd() alone.


--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [fossil all extras] useless without --showfile

[Andy Goth]

On 4/2/2014 11:42 PM, Joe Mistachkin wrote:

Andy Goth wrote:

I'm curious how a script could make use of [fossil extras] without
the benefit of the --showfile option.


The --showfile option is processed by the [fossil all] command, not
the [fossil extras] command, which basically explains the underlying
issue...

The [fossil extras] command itself has never printed the associated
repository information, while the [fossil changes] command has.


Most of that is clear from behavioral observation, but my question still
stands.  I ask the question in reference to your statement:

On 4/2/2014 7:47 PM, Joe Mistachkin wrote:

however, given the implementation of the [fossil extras] command
itself, it would be difficult to make the changes you are suggesting
without breaking backwards compatibility with existing scripts that
may wrap Fossil.


Backwards compatibility is a worthy goal, but I'm not sure how valuable
it is to maintain compatibility with something that could never have
worked in the first place and therefore may not even exist.

Now, an interesting detail.  [fossil changes] has a --header option
which implements the Changes for REPOS at DIRECTORY: headers, but
[fossil extras] does not have anything of the sort.  I see no harm in
adding it to [fossil extras].

The compatibility problem only arises when changing [fossil all] to
supply [fossil extras] with this new --header option, thereby changing
its output format.

A possible compromise is to have [fossil all] only give --header to
[fossil extras] when [fossil all] was not given --showfile.  I suggest
this on the presumption that any existing scripts that actually use
[fossil all extras] must use --showfile, because the output is otherwise
useless except for the limited purpose of saying whether or not there
exist any extra files, though not where exactly they are.

--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [fossil all extras] useless without --showfile

[Joe Mistachkin]

Andy Goth wrote:
 
 A possible compromise is to have [fossil all] only give --header to
 [fossil extras] when [fossil all] was not given --showfile.  I suggest
 this on the presumption that any existing scripts that actually use
 [fossil all extras] must use --showfile, because the output is otherwise
 useless except for the limited purpose of saying whether or not there
 exist any extra files, though not where exactly they are.
 

Excellent idea.  Done here:

https://www.fossil-scm.org/index.html/info/69974aaa19c7

Thanks.

--
Joe Mistachkin

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

Re: [fossil-users] [fossil all extras] useless without --showfile

[Joe Mistachkin]

Andy Goth wrote:
 
 Without the --showfile option, [fossil all extras] just prints filenames 
 relative to the directories in which the repositories were opened.  It's 
 anyone's guess which files go with which directories and which 
 repositories.  Additionally, --showfile prints the names of all 
 directories, not just those that actually have extra files in them.
 

Good point; however, I could actually make a relatively good argument for
why it's not completely useless.

 
 I prefer the behavior of [fossil all changes].  By default it prints the 
 names of both the repositories and directories with changes, plus 
 doesn't print anything for directories with no changes.
 

I would prefer to be consistent as well; however, given the implementation
of the [fossil extras] command itself, it would be difficult to make the
changes you are suggesting without breaking backwards compatibility with
existing scripts that may wrap Fossil.

--
Joe Mistachkin

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

Re: [fossil-users] [fossil all extras] useless without --showfile

[Andy Goth]

On 4/2/2014 7:47 PM, Joe Mistachkin wrote:

Andy Goth wrote:

I prefer the behavior of [fossil all changes].  By default it prints
the names of both the repositories and directories with changes, plus
doesn't print anything for directories with no changes.


I would prefer to be consistent as well; however, given the
implementation of the [fossil extras] command itself, it would be
difficult to make the changes you are suggesting without breaking
backwards compatibility with existing scripts that may wrap Fossil.


I'm curious how a script could make use of [fossil extras] without the
benefit of the --showfile option.

--
Andy Goth | andrew.m.goth/at/gmail/dot/com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [fossil all extras] useless without --showfile

[Joe Mistachkin]

Andy Goth wrote:

 I'm curious how a script could make use of [fossil extras] without the
 benefit of the --showfile option.
 

The --showfile option is processed by the [fossil all] command, not the
[fossil extras] command, which basically explains the underlying issue...

The [fossil extras] command itself has never printed the associated
repository information, while the [fossil changes] command has.

--
Joe Mistachkin

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

[fossil-users] fossil all clean

[j. van den hoff]

regarding this new command: as the help page correctly states Extreme  
caution should be exercised with this command because its effects cannot  
be undone. ...: this could cause real trouble for inexperienced users  
presuming clean is some sort of innocuous tidy up like make clean.  
would it not be wise to change the default behavior to executing a dry-run  
while delegating the actual action to something like fossil clean  
--force? this also would bring the syntax more in line with `fossil  
clean'.


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil all clean

[Joe Mistachkin]

j. van den hoff wrote:

 would it not be wise to change the default behavior to executing a dry-run

 while delegating the actual action to something like fossil clean  
 --force? this also would bring the syntax more in line with `fossil  
 clean'.
 

The only thing 'fossil all clean' really does is to call the 'fossil clean'
command on each local checkout, passing the detected 'fossil clean' command
line options verbatim.

I guess I'm confused about what you are asking for here.

--
Joe Mistachkin

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

Re: [fossil-users] fossil all clean

[j. van den hoff]

On Fri, 18 Oct 2013 09:26:59 +0200, Joe Mistachkin sql...@mistachkin.com  
wrote:




j. van den hoff wrote:


would it not be wise to change the default behavior to executing a  
dry-run



while delegating the actual action to something like fossil clean
--force? this also would bring the syntax more in line with `fossil
clean'.



The only thing 'fossil all clean' really does is to call the 'fossil  
clean'
command on each local checkout, passing the detected 'fossil clean'  
command

line options verbatim.

I guess I'm confused about what you are asking for here.


I interpreted the help text in such a way that it would execute fossil  
clean -f on all repos (and thus did not just try the command out ...). so  
this obviously is a misconception. but in that case it might help to  
clarify the help text as per your explanation above (passing `fossil  
clean' options verbatim)


sorry for the noise.

joerg



--
Joe Mistachkin

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil all rebuild seg faults

[James Turner]

With the latest fossil trunk (This is fossil version 1.24 [bdbe6c74b8]
2012-10-30 18:14:27 UTC) fossil all rebuild is seg faulting for me.

fossil all rebuild
Segmentation fault (core dumped)

gdb is showing the below:

#0  collect_arguments (zArg=0x7f7f Address 0x7f7f out
of bounds) at allrepo.c:61
61  allrepo.c: No such file or directory.
in allrepo.c

-- 
James Turner
ja...@calminferno.net
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil all rebuild seg faults

[Richard Hipp]

Please try the latest and let me know whether or not the problem is fixed.
Tnx for the report.

On Tue, Oct 30, 2012 at 6:31 PM, James Turner ja...@calminferno.net wrote:

 With the latest fossil trunk (This is fossil version 1.24 [bdbe6c74b8]
 2012-10-30 18:14:27 UTC) fossil all rebuild is seg faulting for me.

 fossil all rebuild
 Segmentation fault (core dumped)

 gdb is showing the below:

 #0  collect_arguments (zArg=0x7f7f Address 0x7f7f out
 of bounds) at allrepo.c:61
 61  allrepo.c: No such file or directory.
 in allrepo.c

 --
 James Turner
 ja...@calminferno.net
 ___
 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] fossil all rebuild seg faults

[James Turner]

Looks good. fossil all rebuild is working for me again. If it helps
explain anything, I'm running OpenBSD.

On Tue, Oct 30, 2012 at 08:11:53PM -0400, Richard Hipp wrote:
 Please try the latest and let me know whether or not the problem is fixed.
 Tnx for the report.
 
 On Tue, Oct 30, 2012 at 6:31 PM, James Turner ja...@calminferno.net wrote:
 
  With the latest fossil trunk (This is fossil version 1.24 [bdbe6c74b8]
  2012-10-30 18:14:27 UTC) fossil all rebuild is seg faulting for me.
 
  fossil all rebuild
  Segmentation fault (core dumped)
 
  gdb is showing the below:
 
  #0  collect_arguments (zArg=0x7f7f Address 0x7f7f out
  of bounds) at allrepo.c:61
  61  allrepo.c: No such file or directory.
  in allrepo.c
 
  --
  James Turner
  ja...@calminferno.net
 
 -- 
 D. Richard Hipp
 d...@sqlite.org

-- 
James Turner
ja...@calminferno.net
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil all rebuild seg faults

[Steve Bennett]

On 31/10/2012, at 10:11 AM, Richard Hipp wrote:

 Please try the latest and let me know whether or not the problem is fixed.  
 Tnx for the report.

Regarding your latest commit, I've run across this on 64 bit too.
The problem is the '0' at the end of the variable args.
Use NULL instead, otherwise you only get a 32 bit zero value instead of 64 bit.

Cheers,
Steve

 
 On Tue, Oct 30, 2012 at 6:31 PM, James Turner ja...@calminferno.net wrote:
 With the latest fossil trunk (This is fossil version 1.24 [bdbe6c74b8]
 2012-10-30 18:14:27 UTC) fossil all rebuild is seg faulting for me.
 
 fossil all rebuild
 Segmentation fault (core dumped)
 
 gdb is showing the below:
 
 #0  collect_arguments (zArg=0x7f7f Address 0x7f7f out
 of bounds) at allrepo.c:61
 61  allrepo.c: No such file or directory.
 in allrepo.c
 
 --
 James Turner
 ja...@calminferno.net
 ___
 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

--
Embedded Systems Specialists - http://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] fossil all rebuild seg faults

[Richard Hipp]

On Tue, Oct 30, 2012 at 8:18 PM, Steve Bennett ste...@workware.net.auwrote:

 On 31/10/2012, at 10:11 AM, Richard Hipp wrote:

 Please try the latest and let me know whether or not the problem is
 fixed.  Tnx for the report.


 Regarding your latest commit, I've run across this on 64 bit too.
 The problem is the '0' at the end of the variable args.
 Use NULL instead, otherwise you only get a 32 bit zero value instead of 64
 bit.


I bet you're right.  I've previously made the same mistake using using
Tcl_AppendResult()



 Cheers,
 Steve


 On Tue, Oct 30, 2012 at 6:31 PM, James Turner ja...@calminferno.netwrote:

 With the latest fossil trunk (This is fossil version 1.24 [bdbe6c74b8]
 2012-10-30 18:14:27 UTC) fossil all rebuild is seg faulting for me.

 fossil all rebuild
 Segmentation fault (core dumped)

 gdb is showing the below:

 #0  collect_arguments (zArg=0x7f7f Address 0x7f7f out
 of bounds) at allrepo.c:61
 61  allrepo.c: No such file or directory.
 in allrepo.c

 --
 James Turner
 ja...@calminferno.net
 ___
 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


--
 Embedded Systems Specialists - http://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] fossil all rebuild seg faults

[James Turner]

On Tue, Oct 30, 2012 at 08:22:25PM -0400, Richard Hipp wrote:
 On Tue, Oct 30, 2012 at 8:18 PM, Steve Bennett ste...@workware.net.auwrote:
 
  On 31/10/2012, at 10:11 AM, Richard Hipp wrote:
 
  Please try the latest and let me know whether or not the problem is
  fixed.  Tnx for the report.
 
 
  Regarding your latest commit, I've run across this on 64 bit too.
  The problem is the '0' at the end of the variable args.
  Use NULL instead, otherwise you only get a 32 bit zero value instead of 64
  bit.
 
 
 I bet you're right.  I've previously made the same mistake using using
 Tcl_AppendResult()
 
 

Yeah I'm running amd64, so definitely 64bit over here.

 
  Cheers,
  Steve
 
 
  Embedded Systems Specialists - http://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
 
 
 -- 
 D. Richard Hipp
 d...@sqlite.org

-- 
James Turner
ja...@calminferno.net
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil all ignore

[Ramon Ribó]

   Hello,

   Currently the help of fossil all says:

Respositories are automatically added to the set of known repositories
when one of the following commands are run against the repository: clone,
info, pull, push, or sync.

   Would not be more logical that it where:

Respositories are automatically added to the set of known repositories
when one of the following commands are run against the repository:
new,clone, open,
 pull, push, or sync

fossil info is a very common operation an nearly invalidates the use
of:

fossil all ignore


PS: As always, this kind of things become important when using fossil as a
tool for another
 program of when making a GUI for fossil


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