Ok,
Tried all previous suggestions and no go.
Had a chance to do something very simple, but my experience was the same.
I add a single LARGE file to my repo.
I commit.
I delete that LARGE file.
I commit.
I rebuild.
The repo file size still contains the LARGE file in the blob table.
Can I delete
On Tue, Sep 11, 2012 at 3:51 PM, sky5w...@gmail.com wrote:
Ok,
Tried all previous suggestions and no go.
Had a chance to do something very simple, but my experience was the same.
I add a single LARGE file to my repo.
I commit.
I delete that LARGE file.
I commit.
I rebuild.
The repo file
Ok, that removes the file from display, but the size of my repo has
been permanently grown by the unwanted large file.
Is that by design?
I am right back at the beginning of this post.
What if I or some other developer or some virus added ~../*.* ?
Would I/Should I be forever saddled with the new
On Tue, Sep 11, 2012 at 6:22 PM, sky5w...@gmail.com wrote:
Ok, that removes the file from display, but the size of my repo has
been permanently grown by the unwanted large file.
Is that by design?
Try fossil rebuild --vacuum and let us know if that fixes it.
I am right back at the
tada! That worked!
Question:
How come I cannot use fossil shun a large file sha1 from a command line?
I can only shun from the ui?
That makes it difficult to automate if there are hundreds of files to shun. :(
Thanks for fossil.
On Tue, Sep 11, 2012 at 6:44 PM, Richard Hipp d...@sqlite.org
On Sun, Sep 2, 2012 at 5:57 AM, Altu Faltu altufa...@mail.com wrote:
Two things could have helped here:
1. A rollback feature that could undo last N commits. I think rollback
feature is in todo list. Not sure what would it do if repo was ayned to
some other one in between.
That is indeed
I'm not sure if you are saying you no longer have the list of filenames or
you no longer have the uuid's of those files to shun.
If you no longer have the list of filenames, you can obtain the full list
from
$ fossil sqlite
sqlite .output filenames.txt
sqlite select name from filename
: [fossil-users] Please make shunning a first class feature.
Actually, it was hundreds of files that were added recursively with ..\*.* I
am back to sanity now, but I have not heard an adequate response for such a
simple mistake? Knowing now that shunning was NOT the correct action in my
case
On Thu, Aug 30, 2012 at 8:58 PM, sky5w...@gmail.com wrote:
When adding files, the permanence should be stated somewhere in the doc's.
FWIW, it's implied in the product's name and stated as clear as day in the
first line of the shunning docs:
Fossil is designed to keep all historical content
Yes, yes I get it.
But thinking more deeply on what 'fossil' implies...
I truly want ONLY the fossil and NOT the entire beast! :))
(The record of existence, but not all the pounds too...)
On Fri, Aug 31, 2012 at 4:45 AM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Aug 30, 2012 at 8:58 PM,
Hello,
Sorry to say, I have come up against this same scenario.
After shunning and rebuilding, my repo still contains some 180MB of
mistaken files. :(
They do not appear in the Timeline or Files listing, but the repo
contains them nonetheless.
What is the safest and most efficient way to return my
Have you rebuild the repository?
fossil rebuild
Jonas Malaco Filho
Sent from my iPhone
On 30/08/2012, at 13:44, sky5w...@gmail.com sky5w...@gmail.com wrote:
Hello,
Sorry to say, I have come up against this same scenario.
After shunning and rebuilding, my repo still contains some 180MB of
Yes, and it did take more than a minute or so.
But the before and after sizing of the repo remained nearly the same.
On Thu, Aug 30, 2012 at 1:08 PM, Jonas Malaco Filho
jonasmalacofi...@gmail.com wrote:
Have you rebuild the repository?
fossil rebuild
Jonas Malaco Filho
Sent from my iPhone
On 30/08/2012, at 13:44, sky5w...@gmail.com sky5w...@gmail.com wrote:
Hello,
Sorry to say, I have come up against this same scenario.
After shunning and rebuilding, my repo still contains some 180MB of
mistaken files. :(
They do not appear in the Timeline or Files listing, but the
The offending files were added only in 4 sequential artifacts or commits.
I shunned those 4 and performed a rebuild and the visible record is
wiped, but the size is still wrong.
On Thu, Aug 30, 2012 at 1:13 PM, Tomek Kott tkott.li...@outlook.com wrote:
On 30/08/2012, at 13:44,
Hello
I did not try this but I think cloning should not copy shunned artifacts.
So you can create a smaller repo by making another clone.
HTH
Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
If I view the fossil repo in a SQLite browser, there are several very
large blobs, but I cannot safely remove these without knowledge?
On Thu, Aug 30, 2012 at 1:16 PM, sky5w...@gmail.com wrote:
The offending files were added only in 4 sequential artifacts or commits.
I shunned those 4 and
I feel like there may have been another step needed. Like:
fossil ui
Then Admin, Shunned, then a button to remove shunned artifacts.
I could be wrong. I think I have a repository with some shuns somewhere
but don't know which, and with no shuns I see no controls.
On 08/30/2012 12:18 PM,
No luck using
c:\ fossil clone myrepo.fossil myrepo2.fossil
Sizes are the same.
My question is should I shun even more or just go back to an earlier
repo before the addfiles error?
I'm not getting a warm fuzzy about fossil shunning inadvertent files :(
On Thu, Aug 30, 2012 at 1:22 PM, Nolan
Not sure if it makes sense (since I know exactly how clone works), but
could there be unused pages in the sqlite layer?
sqlite VACUUM;
Jonas Malaco Filho
Sent from my iPhone
On 30/08/2012, at 14:33, sky5w...@gmail.com sky5w...@gmail.com wrote:
No luck using
c:\ fossil clone myrepo.fossil
Well, VACUUM removed 500kB. Still 179MB to go...
On Thu, Aug 30, 2012 at 1:36 PM, Jonas Malaco Filho
jonasmalacofi...@gmail.com wrote:
Not sure if it makes sense (since I know exactly how clone works), but
could there be unused pages in the sqlite layer?
sqlite VACUUM;
Jonas Malaco Filho
As stated here: http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki,
rebuilding should be enough to clear them out. I am guessing that since you
only shunned the manifest artifact (the commit), only those were removed,
which are not very big, and you now have orphaned artifacts not
The offending files were added only in 4 sequential artifacts or commits.
I shunned those 4 and performed a rebuild and the visible record is
wiped, but the size is still wrong.
Right. So on the first commit, you have a artifact for the commit, and an
artifact for each file in that commit.
Ok, really frustrating, since I now shunning all artifacts from this week.
Then rebuild.
Still ~180MB of data somewhere in the repo! :(
I had not previously trouble shot this error condition but only read
about it in the mail archives.
A seemingly simple add files CANNOT be undone by me.
Unless
*Thanks Baruch, I will try anything at this point.
Yes, Tomek, what you imply makes sense, but how do I search for
artifacts of individual files once shunned from the timeline and
files?
Erg, that I can't help with. It sounds like Baruch and I were saying the same
thing. Baruch might
Ok Baruch, I will try your sql if you have a suggestion.
Is this really a bug?
On Thu, Aug 30, 2012 at 2:32 PM, Tomek Kott tkott.li...@outlook.com wrote:
*Thanks Baruch, I will try anything at this point.
Yes, Tomek, what you imply makes sense, but how do I search for
artifacts of individual
I see now that sql wouldn't be able to find it, since the shuned artifact
loses it's rid, and all other tables refer to it by it rid. I would try to
get an answer from Dr. Hipp, but it may be lost.
On Thu, Aug 30, 2012 at 9:38 PM, sky5w...@gmail.com wrote:
Ok Baruch, I will try your sql if you
Makes sense, since I am browsing the database with SQLite Expert and
there are no Filename entries for me to purge after the shun.
I really think this is a flaw if not a bug.
When adding files, the permanence should be stated somewhere in the doc's.
I think it was, but I had no luck using the
Ha, that is also a flaw or bug!
Once a file is deleted should not mean I can never reconsider adding
it in the future.
On Thu, Aug 30, 2012 at 3:16 PM, Baruch Burstein bmburst...@gmail.com wrote:
Just a note on whether this is a bug or not. I thought it was, but if files
changed by a shuned
-0400
From: sky5w...@gmail.com
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Please make shunning a first class feature.
Ha, that is also a flaw or bug!
Once a file is deleted should not mean I can never reconsider adding
it in the future.
On Thu, Aug 30, 2012 at 3:16
history, so this wouldn't be a bug or flaw.
Hence the whole mantra that each and every object has its own artifact.
Remember, file != artifact.
Tomek
Date: Thu, 30 Aug 2012 15:38:42 -0400
From: sky5w...@gmail.com
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Please make
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Please make shunning a first class feature.
Well, I would love a sql that could return all orphaned files?
Then I could remove them according to some id.
On Thu, Aug 30, 2012 at 3:43 PM, Tomek Kott tkott.li...@outlook.com wrote:
I
or flaw.
Hence the whole mantra that each and every object has its own artifact.
Remember, file != artifact.
Tomek
Date: Thu, 30 Aug 2012 15:38:42 -0400
From: sky5w...@gmail.com
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Please make shunning a first class feature
on the right
track. I don't know what to look for past that.
Tomek
Date: Thu, 30 Aug 2012 15:53:43 -0400
From: sky5w...@gmail.com
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Please make shunning a first class feature.
Well, I would love a sql that could return all
On Thu, Aug 30, 2012 at 3:38 PM, sky5w...@gmail.com wrote:
Ha, that is also a flaw or bug!
Once a file is deleted should not mean I can never reconsider adding
it in the future.
No, its a feature.
Once you shun an artifact, you don't want it to be added back to your
repository when you sync
Heretofore, fossil has been a great product.
I will test this error case again when I have more time.
To call this is a feature is salt in a wound, now several hours
exposed to the air.
I am back from a 200MB repo to a 2MB repo by using another great tool: 7zip :)
On Thu, Aug 30, 2012 at 4:14
Richard,
First, are related artifacts automaticaly removed when their parent is
shunned (and the repo has been rebuilt)? If so, how could I find out which
artifacts are now orphans?
Jonas Malaco Filho
Sent from my iPhone
On 30/08/2012, at 17:15, Richard Hipp d...@sqlite.org wrote:
On Thu, Aug
On Thu, Aug 30, 2012 at 4:43 PM, Jonas Malaco Filho
jonasmalacofi...@gmail.com wrote:
Richard,
First, are related artifacts automaticaly removed when their parent is
shunned (and the repo has been rebuilt)?
No. And furthermore they shouldn't be.
Shunning is a very sharp tool. It is not
Actually, it was hundreds of files that were added recursively with ..\*.*
I am back to sanity now, but I have not heard an adequate response for
such a simple mistake?
Knowing now that shunning was NOT the correct action in my case.
I ask simply, what should I have done?
Delete individual file
Yes, it makes sense.
Now how can someone search for orphaned artifacts (so that those can be
handled)? For instance, I want to check (and correct) if I made a mistake
just when I was just starting to use fossil and did some improper
shunning. Also, on a related topic: I found (searching the list
On 8/30/12, sky5w...@gmail.com sky5w...@gmail.com wrote:
Actually, it was hundreds of files that were added recursively with ..\*.*
I am back to sanity now, but I have not heard an adequate response for
such a simple mistake?
Knowing now that shunning was NOT the correct action in my case.
I
Ok, this is definitely a case of if I knew then what I know now I
could proceed as you say.
The problem is I read the shunning instructions and did not see
mention of possible orphaning of my files.
Once I shunned the artifacts that triggered the file additions
(thought it made sense), I was
On Fri, Jan 7, 2011 at 7:46 PM, James Bremner ravenspo...@yahoo.com wrote:
With the hands on help of Richard Hipp I have got my repository up and
running again. I am very grateful for this. But it seems that now my
repository must limp along with warnings about checksums and a suspicion
On Fri, Jan 7, 2011 at 4:25 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jan 7, 2011 at 7:46 PM, James Bremner ravenspo...@yahoo.comwrote:
With the hands on help of Richard Hipp I have got my repository up and
running again. I am very grateful for this. But it seems that now my
44 matches
Mail list logo
