I’ve created a ticket on a publicly served repository, and entered a
contact e-mail address for the ticket. When I edit the ticket, I can
see the e-mail address fine. After synchronizing my local
repository, viewing the ticket using `fossil ui` locally, the ticket
shows up
Can someone help me understand the conflict-resolving procedure. This is
what happens:
I have a private branch. I merge the trunk into it:
fossil update my-branch
fossil merge trunk
I then get a warning about 3 merge conflicts. I go to those files and see I
have 4(!) of each. A baseline,
On Thu, Aug 30, 2012 at 5:28 AM, Baruch Burstein bmburst...@gmail.comwrote:
Can someone help me understand the conflict-resolving procedure. This is
what happens:
I have a private branch. I merge the trunk into it:
fossil update my-branch
fossil merge trunk
I then get a warning about 3
On Thu, Aug 30, 2012 at 11:28 AM, Baruch Burstein bmburst...@gmail.com wrote:
So, basically it is 3 questions:
1) Does TortoiseMerge not work with fossil (maybe it sends the command line
parameters wrong?)
You probably need the correct settings for TortoiseMerge, which I don't know.
These
Richard Hipp drh@... writes:
RH Only authorized users are
RH allowed to clone or sync the CONCEALED table, and hence only authorized
RH users are able to see the sensitive information.
MC So what determines who is authorized?
RH The user doing the syncing needs to have e permissions in their
I just tried building fossil on windows with mingw-w64 (without msys or
such), which used to work almost flawlessly (I used to only have to change
rm to del and cp to copy). But I found that it doesn't work anymore since
the TRANSLATE variable in the makefile now has forward slashes instead of
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
Baruch Burstein wrote:
I just tried building fossil on windows with mingw-w64 (without msys or
such),
which used to work almost flawlessly (I used to only have to change rm to
del
and cp to copy).
How as this version of MinGW installed? Via the official installer? Do you
have
version
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
No installer. RubenVB's latest build for x64. But the problem isn't mingw,
it is that the windows cmd line interprets this: `wbld/translate.exe` as a
call to `wbld` with parameter `/translate.exe`. There is no problem with
forward slashes in the parameters of a command, just in the command itself.
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
On Thu, Aug 30, 2012 at 9:25 PM, Joe Mistachkin sql...@mistachkin.comwrote:
Baruch Burstein wrote:
No installer. RubenVB's latest build for x64.
Ok, that project (MinGW-w64) is a fork of the official project. The
official project
is here:
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
Can you see if this change clears the issue for you:
http://www.fossil-scm.org/index.html/info/773fa5e63c
--
Joe Mistachkin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
I think if you added a new file, it would get it's own artifact (and uuid), and
know nothing of the prior 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
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 think if you added a new file, it would get it's own artifact (and uuid),
and know nothing of the prior
try
fossil sql -R REPO
then inside, select * from orphan. I don't have any in my table, but I
haven't shunned anything either. That might get you going 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:
For some reason that is not clear to me, these files don't seem to be
marked orphaned (at least in my quick test that is what I saw).
Tomek-
If it is the same file, it will have the same uuid.
On Thu, Aug 30, 2012 at 10:53 PM, sky5w...@gmail.com wrote:
Well, I would love a sql that could
I tried that before an discovered 2 things: They weren't in the orphaned
table and even if they were, the orphaned table only stores their rid in
the blob table, where their uuid would be stored, but since they are
shuned, they are not in the blob table, and have no rid, and so you can't
find
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
Yes, that works, thank you.
It seems to me though, that since msys accepts windows-style paths, it
makes sense to just always use the backslash.
On Thu, Aug 30, 2012 at 10:43 PM, Joe Mistachkin sql...@mistachkin.comwrote:
Can you see if this change clears the issue for you:
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
43 matches
Mail list logo
