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 a
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 n
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)
>
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
> 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
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 checko
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 o
Scott Robison
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
On Sat, Aug 1, 2015 at 4:36 AM, Gour 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
>
On Tue, Oct 28, 2014 at 7:21 PM, wrote:
> could this file syncing also work with FTP
>
No. There needs to be a process that understands the Fossil repository on
both ends. That does not exist on the remote side in the case of FTP.
It works for http: and https: because the remote side process
(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 wrote:
I use mostly Windows, but every so often I open the repo
> Message: 7
> Date: 27 Oct 2014 09:50:39 -0600
> From: "Andy Bradford"
> To: "Tony Papadimitriou"
> Cc: Fossil SCM user's discussion
> 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 fil
On Mon, Oct 27, 2014 at 2:44 PM, Richard Hipp wrote:
> (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"
> ...
> Then take the thumb drive home and do "fossil
On Mon, Oct 27, 2014 at 9:38 AM, Sean Woods 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 m
On Mon, Oct 27, 2014 at 9:30 AM, Tony Papadimitriou 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 except
On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou
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 tw
I use mostly Windows, but every so often I open the repo on a Linux box (but I
can do without Linux for now).
From: Richard Hipp
Sent: Monday, October 27, 2014 3:13 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FOSSIL ALL
On Mon, Oct 27, 2014 at 6:58 AM,
On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou 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
On Mon, Oct 27, 2014 at 8:30 AM, Stephan Beal 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
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 wrote:
>
>> I have sev
On Mon, Oct 27, 2014 at 1:18 PM, Tony Papadimitriou wrote:
> 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
On Mon, Oct 27, 2014 at 12:48 PM, Tony Papadimitriou 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
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 co
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 wrote:
I have several repos open at the same time, not always the same ones. Befo
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
On Mon, Oct 27, 2014 at 6:58 AM, Tony Papadimitriou 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
On Mon, Oct 27, 2014 at 11:58 AM, Tony Papadimitriou wrote:
> /somepath/a.fossil
> /otherpath/b.fossil (OPEN)
>
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.
> And, how about a command to close all open repos at once, e.
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
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 un
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]
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
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 o
On Fri, 18 Oct 2013 09:26:59 +0200, Joe Mistachkin
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 `
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' rea
On Tue, Oct 30, 2012 at 08:22:25PM -0400, Richard Hipp wrote:
> On Tue, Oct 30, 2012 at 8:18 PM, Steve Bennett wrote:
>
> > 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.
> >
> >
> > Regard
On Tue, Oct 30, 2012 at 8:18 PM, Steve Bennett wrote:
> 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
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, otherwis
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
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 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.
>
> f
40 matches
Mail list logo
