Re: [fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Ron W]

On Mon, May 30, 2016 at 4:39 PM, John P. Rouillard  wrote:
>
> In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>,
> Ross Berteig writes:
> >One of the hooks is "command_hook" which is invoked for every
> >fossil command. That name can raise an error (or call break or
> >continue) to prevent the fossil command from executing.
> >
> >Since the hook is called early, it knows the command name, its
> >arguments, its flags, and not a lot lse.
>
> Well if the hook was executed, I could use it to reject a
> --no-th-hooks, but ironically it would never see it 8-).


On any distributed VCS, hooks are like training wheels. They help the user
follow process, but a determined user can take them off.

I hadn't seen documentation on command_hook, but it does get executed
before the list of files with changes is "calculated" so would have to
(somehow) duplicate that functionality.

However I would expect the server would run the hook on an
> incoming commit.
>
> Hmm, now that I think about it, are all the hooks defined in the
> "transfer"(xfersetup) admin page, so they are only run on the
> client?


I think the receiving server also runs hooks, but I don't know.

I don't see where to configure the command_hook on any of the admin pages,
but I'm using the 1.34 released version, not the latest development version.

>The fossil -no-th-hooks option will skip all hooks for that
> >command.  Depending on what else you do in a hook, that might be
> >more than you wanted.
>
> Yup. The embedded codeword allowed fine grain tuning of the
> checks and also recorded whet the developer requested so s/he was
> accountable for the bypass. If any client can disable hooks on
> the remote central repo without any logging/accountability this
> is all moot.


Hooks can only be disabled locally.

Of course, Fossil will have a record of the commit and who did it. So, you
use an assumption of "bypassed unless proven otherwise".

>>Is there some similar way to inspect the transferred artifacts
> >>and file contents and roll back the commit?
> >
> >Nope. And there can't be. Nothing is transferred until well
> >after the whole collection of artifacts that make up the commit
> >have been created and safely stowed in the local
> >repository. There is no "roll back" from that.
>
> Err, that's unfortunate. I was expecting that the order of operations
> for a commit on the server (or a local repo) would be:
>
>   open connection to client (or in the case of local file access,
> just open the sqlite file)
>

When you run "fossil commit", Fossil is directly updating the database
residing on you PC.

If "auto-sync" is turned on, Fossil will automatically pull from the remote
server before processing the commit, then automatically push to the remote
server after processing the commit, but the commit process itself is local
only.

When a remote Fossil server receives a commit from your local repo, it
could run its own commit hook. I don't know if does. Right now, as best I
can tell, only a post_commit hook is available.

I'm not sure all of the implications and collateral damage of a pre_commit
hook on a receiving server. Fossil's current approach is to block all
pushes from users not authorized to push. (Contributions from those users
can, however, be pulled, in which case, Fossil records both who made te
commit and who pulled the commit.)


>   start transaction in database

[...]

> commit transaction
>

Internally, "fossil commit" does this. It just doesn't have a hook just
before committing the database transaction.

However, on a receiving server, commit processing is much simpler.

Overall it sounds that wrapping tools are required to support
> process and validation with fossil rather than supporting the
> process within fossil.
>

At least for "fossil commit", a workable pending_commit hook could be
implemented. Though there is a complication: any commit that has a "base
line" manifest (as opposed to "delta manifest") will list all "current"
artifacts, not just those changed by the commit, so the hook would also
need a way to get a list of artifacts for just the changed files.
___
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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[John P. Rouillard]

Hi Ross:

In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>,
Ross Berteig writes:
>On 5/27/2016 3:58 PM, John P. Rouillard wrote:
>> Hi Richard:
>>
>> Richard Hipp writes:
>>> Just to be clear, I consider anything involving shunning to be
>>> out-of-the-ordinary.
>>
>> Perfectly reasonable.
>>
>> On that note, does anybody have code for tcl hooks that can be used to
>> reject artifacts that have text that matches a particular pattern
>
>IMHO, that is capability is outside the core mission of
>fossil. One of the great selling points of fossil to new users
>is the low ceremony of fossil. One executable. A repo is a
>single file, that can even safely reside in the same folder as
>your checkout. And very little policy is enforced by fossil
>directly.

I agree that the low ceremony feature of fossil is excellent. I
am *not* suggesting that the th1/tcl code to enforce policy be
supplied by default. However I was expecting that the fossil
hooks would operate similar to hooks/triggers (and similar
mechanisms) in svn, cvs, git, perforce 

>That said, there is a hook mechanism that can be used to check
>preconditions before executing a command. It might require some
>cleverness to use it for this purpose, however.

Yup, cleverness is what I am looking for. I was expecting that I
could do the following from a hook:

  1) Get the current manifest for the checkin (passed to the hook
 script)
  2) Using the manifest, find a list of new artifacts added
 in this commit transaction (e.g from th1: 
 set manifest [fossil artifact ]
 )
  3) Analyze the manifest for filenames and artifact id's and be
 able to "fossil artifact" these new artifacts to analyze the
 contents
  4) verify the checkin comment contents (by looking for the C
 card in the manifest): E.G. does the checkin comment have a
 reference to an open ticket.
  5) Identify the user who made the commit (U card in manifest IIRC)
  6) Abort the commit from the hook causing the artifacts be
 removed and the user to be notified with a message from the
 hook script.

However from what you say below it looks like the hook is at the
wrong level for me to do any of this.

>Hooks exist if fossil is compiled with the option, are written
>in TH1, can configured to make Tcl available to TH1, and are not
>extensively documented.

So I have noted 8-). Even some light code groveling failed to
enlighten me.

>One of the hooks is "command_hook" which is invoked for every
>fossil command. That name can raise an error (or call break or
>continue) to prevent the fossil command from executing.
>
>Since the hook is called early, it knows the command name, its
>arguments, its flags, and not a lot lse.

Well if the hook was executed, I could use it to reject a
--no-th-hooks, but ironically it would never see it 8-).

>Hence the need for cleverness since you would want to learn what
>files are going to be committed.
>
>This hook has to run at the client, and before the commit is
>performed.  So that won't prevent a user from bypassing it, or a
>misconfigured repository from failing to call it, or if depending
>on Tcl, I'm sure there are more failure modes since Tcl is
>(usually, depending on configuration of fossil) loaded from the
>system at run time.

Agreed. I would expect that only the central repo would be
guaranteed to run the hook, but that doesn't stop repo clones
from also having the hooks so that they don't commit things that
would be rejected upstream.

Obviously I would also need access in the hook to see if the
branch is private or not so I could bypass the hook on a private
branch (that won't be pushed upstream).

However I would expect the server would run the hook on an
incoming commit.

Hmm, now that I think about it, are all the hooks defined in the
"transfer"(xfersetup) admin page, so they are only run on the
client?

>>   If you really wanted to commit a file that matched that
>> pattern, you added a string like: BYPASSPASSWORD to the commit
>> message and the check would be bypassed.
>
>The fossil -no-th-hooks option will skip all hooks for that
>command.  Depending on what else you do in a hook, that might be
>more than you wanted.

Yup. The embedded codeword allowed fine grain tuning of the
checks and also recorded whet the developer requested so s/he was
accountable for the bypass. If any client can disable hooks on
the remote central repo without any logging/accountability this
is all moot.

>>Is there some similar way to inspect the transferred artifacts
>>and file contents and roll back the commit?
>
>Nope. And there can't be. Nothing is transferred until well
>after the whole collection of artifacts that make up the commit
>have been created and safely stowed in the local
>repository. There is no "roll back" from that.

Err, that's unfortunate. I was expecting that the order of operations
for a commit on the server (or a local repo) would be:

  open connection to client (or in the case of 

Re: [fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Stephan Beal]

On Sat, May 28, 2016 at 7:59 AM, Andy Gibbs  wrote:

>
> Thanks, that was exactly the set of answers I was looking for.  I now
> understand the problem and can avoid it in future.  Having done some tests
> it
> seems that the "fossil rebuild" actually caused the problem -- fossil
> doesn't
> cause the manifest file to appear as a timeline entry on commit itself.


Right - at commit-time fossil generates a manifest and doesn't check the
contents of any other files to see if they're one (there's no need to).
During a rebuild, fossil scans every blob to see if it's a manifest, and
treats it as such if it is.


>   But
> Richard, since...
>
> > Just to be clear, I consider anything involving shunning to be
> > out-of-the-ordinary.
>
> what then is the best way to clear up the repository history, in particular
> these to rogue (but it turns out entirely expected) timeline entries?
> Branch hiding?
>

One of fossil's core-most philosophies is that history cannot be changed.
Branch hiding will get them out of view, but only for casual observers.
Because they're harmless (though admittedly confusing), my answer to your
question would be: why bother? IMO doing so is more trouble than it's
worth, in particular since it's only a "superficial" form of hiding. To
quote River Tam: "it's still there. Waiting."


-- 
- 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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Andy Gibbs]

On Fri, May 27, 2016 at 10:00 PM, Stephan Beal wrote:
> On Fri, May 27, 2016 at 6:39 PM, Andy Gibbs wrote:
> 
>>File 3rdparty/chromium/third_party/sqlite/sqlite-src-3080704/manifest -
>> part of check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - **
>> message elided **
>>File 3rdparty/chromium/third_party/sqlite/src/manifest - part of
>> check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** message
>> elided **
>>
>
> That's the source of your... troubles is not quite the word (see below). In
> fossil, any content which looks like a manifest, is a manifest and will be
> treated as such. There is no marking of "that is a manifest" - it's
> determined by checking "can it be parsed as a manifest?"
> 
> To quote:
> 
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki
> 
> "Any artifact in the repository that follows the syntactic rules of a
> manifest is a manifest. Note that a manifest can be both a real manifest
> and also a content file, though this is rare."
>
> [...]
>
>> So, I certainly don't want to shun this artifact because then I'll lose a
>> file from a valid check-in -- isn't that right?
>
> i believe that's correct.
>
>> But how can I fix it?
>
> This is how fossil behaves, so there's nothing to fix :/.

Stephan,

Thanks, that was exactly the set of answers I was looking for.  I now 
understand the problem and can avoid it in future.  Having done some tests it 
seems that the "fossil rebuild" actually caused the problem -- fossil doesn't 
cause the manifest file to appear as a timeline entry on commit itself.  But 
Richard, since...

> Just to be clear, I consider anything involving shunning to be
> out-of-the-ordinary.

what then is the best way to clear up the repository history, in particular 
these to rogue (but it turns out entirely expected) timeline entries?
Branch hiding?

Cheers
Andy

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

Re: [fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Eric Rubin-Smith]

> On May 27, 2016, at 12:26, Andy Gibbs  wrote:
> 
> Hi,
> 
> I've just had a very, very odd experience with fossil.  I'm running version 
> 1.34.
> 
> Let me first explain what I have done.
> 
> I cloned a respository off our server.  I then went into the clone's web UI 
> and disabled the auto-sync feature.  I then made 7 commits, the first of 
> which caused a trunk fork which I then "repaired" by branching the old 
> tip-of-trunk that caused the fork.  I then committed two commits to the new 
> branch, then realised that I'd committed the wrong code, so shunned the last 
> two commits, rebuilt the respository, unshunned the sha1 signatures, rebuilt, 
> then recommitted the last two commits using the correct code.
> 
> Ok, a little complicated but nothing too out-of-the-ordinary, I hope.
> 
> Except ... now I have two utterly random commits in my cloned repository - 
> both seemingly from the sqlite repository:
> 
> 2014-12-09 [f66f7a17b7] Version 3.8.7.4 (user: drh, tags: release, 
> version-3.8.7.4)
> 2011-05-19 [ed1da510a2] Version 3.7.6.3 release candidate 1. (user: drh)

If you commit a file that looks like a fossil manifest, then fossil treats it 
as such and displays the commits listed therein as if they happened in your 
actual repository.  Or something. I had this happen to me too a while back when 
I did the same thing, importing the SQLite tree wholesale into another fossil 
repo.  Drh said at the time that there's no "real" corruption.  

Sent from my iPhone


> 
> Now, it is true that I have a clone of the sqlite respository on my server 
> too ... but I haven't yet synced with the server.  Absolutely no server 
> communication has happened since my initial clone.  And these odd artifacts 
> were definitely not there (or, rephrased, definitely not showing) when I was 
> mid-way through all of this work, and are not there on the server's copy of 
> the repository either.
> 
> Unfortunately, I cannot say exactly when these artifacts appeared, but my 
> hunch would be somepoint around the shunning/rebuilding process?  Does this 
> even make sense?!?
> 
> Worse, I am left not sure whether to simply shun the two random artifacts and 
> then push the changes to the repository up to the server.  It has taken the 
> best part of a day to get all these commits in and it represents about 6GB of 
> source files (the repository has doubled from ~700 MB to ~1.5 GB) requiring a 
> lot of manual "fossil mv"s to synchronise many moved files (fossil doesn't 
> yet support a git-like auto-mv-detection sadly).
> 
> Any idea how I can easily check the validity of my repository?  I have done 
> the obvious which is to check out each of the recent check-ins and compare 
> them with the original source folders, but what I don't know is whether the 
> structure of my respository is damaged in some way...
> 
> Help :o)
> 
> Thanks!
> Andy
> 
> ___
> 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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Ross Berteig]

On 5/27/2016 3:58 PM, John P. Rouillard wrote:

Hi Richard:

Richard Hipp writes:

Just to be clear, I consider anything involving shunning to be
out-of-the-ordinary.


Perfectly reasonable.

On that note, does anybody have code for tcl hooks that can be used to
reject artifacts that have text that matches a particular pattern


IMHO, that is capability is outside the core mission of fossil. One of 
the great selling points of fossil to new users is the low ceremony of 
fossil. One executable. A repo is a single file, that can even safely 
reside in the same folder as your checkout. And very little policy is 
enforced by fossil directly.


Aside, of course, from the big one: fossil preserves everything, and 
that history is immutable.


That said, there is a hook mechanism that can be used to check 
preconditions before executing a command. It might require some 
cleverness to use it for this purpose, however.


Hooks exist if fossil is compiled with the option, are written in TH1, 
can configured to make Tcl available to TH1, and are not extensively 
documented. One of the hooks is "command_hook" which is invoked for 
every fossil command. That name can raise an error (or call break or 
continue) to prevent the fossil command from executing.


Since the hook is called early, it knows the command name, its 
arguments, its flags, and not a lot else. Hence the need for cleverness 
since you would want to learn what files are going to be committed.


This hook has to run at the client, and before the commit is performed. 
So that won't prevent a user from bypassing it, or a misconfigured 
repostory from failing to call it, or if depending on Tcl, I'm sure 
there are more failure modes since Tcl is (usually, depending on 
configuration of fossil) loaded from the system at run time.




If you really wanted to commit a file that matched that pattern, you
added a string like: BYPASSPASSWORD to the commit message and the
check would be bypassed.


The fossil -no-th-hooks option will skip all hooks for that command. 
Depending on what else you do in a hook, that might be more than you wanted.



Is there some similar way to inspect the transferred artifacts and
file contents and roll back the commit?


Nope. And there can't be. Nothing is transferred until well after the 
whole collection of artifacts that make up the commit have been created 
and safely stowed in the local repository. There is no "roll back" from 
that.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Ron W]

On Fri, May 27, 2016 at 6:58 PM, John P. Rouillard  wrote:

>
> On that note, does anybody have code for tcl hooks that can be used to
> reject artifacts that have text that matches a particular pattern.


The closest Fossil has to this is the "commit permission", which blocks the
commit based on the user ID.

Otherwise, to "roll back" a commit requires shunning the manifest.
(Shunning the files is also possible, but you have to be careful to only
shun the ones that actually changed in that commit).

Either way, the originating repo will still have the commit.
___
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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Richard Hipp]

On 5/27/16, Andy Gibbs  wrote:
>
> Ok, a little complicated but nothing too out-of-the-ordinary, I hope.
>

Just to be clear, I consider anything involving shunning to be
out-of-the-ordinary.
-- 
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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Stephan Beal]

On Fri, May 27, 2016 at 6:39 PM, Andy Gibbs  wrote:

>File 3rdparty/chromium/third_party/sqlite/sqlite-src-3080704/manifest -
> part of check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - **
> message elided **
>File 3rdparty/chromium/third_party/sqlite/src/manifest - part of
> check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** message
> elided **
>

That's the source of your... troubles is not quite the word (see below). In
fossil, any content which looks like a manifest, is a manifest and will be
treated as such. There is no marking of "that is a manifest" - it's
determined by checking "can it be parsed as a manifest?"

To quote:

http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki

"Any artifact in the repository that follows the syntactic rules of a
manifest is a manifest. Note that a manifest can be both a real manifest
and also a content file, though this is rare."




> And the other artifact is the similar.  Could this account for the odd
> behaviour?  Fossil has somehow got confused about an actual commit and a
> manifest file that has been checked in?
>

It's not confused - this is how it works. Admittedly, a bit confusing, but
AFAIK harmless. Once, while testing libfossil's manifest parser, i
inadvertently imported a manifest from the main fossil tree into it, and
was very surprised to see a commit with the username "drh". It didn't break
anything (somewhat surprisingly).


> So, I certainly don't want to shun this artifact because then I'll lose a
> file from a valid check-in -- isn't that right?


i believe that's correct.


> But how can I fix it?
>

This is how fossil behaves, so there's nothing to fix :/.

-- 
- 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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Andy Gibbs]

Hi again,

I've just discovered something and maybe it is helpful.  I checked the 
"artifact" webpage for both of these rogue artifacts, and I get multiple 
sources for the artifact in question, e.g.:


http://localhost:8080/artifact/f66f7a17b7

Artifact f66f7a17b78ba617acde90fc810107f34f1a1f2e:

   File 3rdparty/chromium/third_party/sqlite/sqlite-src-3080704/manifest - 
part of check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** 
message elided **
   File 3rdparty/chromium/third_party/sqlite/src/manifest - part of 
check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** message 
elided **


Also Manifest of check-in [f66f7a17b7] - Version 3.8.7.4 by drh on 
2014-12-09 01:34:36.


   C Version\s3.8.7.4
   D 2014-12-09T01:34:36.054
   F Makefile.arm-wince-mingw32ce-gcc 
d6df77f1f48d690bd73162294bbba7f59507c72f

   F Makefile.in cf57f673d77606ab0f2d9627ca52a9ba1464146a
   F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23
   F Makefile.msc e31dee24038965fb6269d6d61073fd6b7e331dec
   F Makefile.vxworks 034289efa9d591b04b1a73598623119c306cbba0
   F README.md 64f270c43c38c46de749e419c22f0ae2f4499fe8
   F VERSION d7e46e14bd7393d54d19ad900222e5f20d41ea1b
   ...

And the other artifact is the similar.  Could this account for the odd 
behaviour?  Fossil has somehow got confused about an actual commit and a 
manifest file that has been checked in?


So, I certainly don't want to shun this artifact because then I'll lose a 
file from a valid check-in -- isn't that right?  But how can I fix it?


Thanks again for your help in my hour of need :o)

Andy


- Original Message - 
From: "Andy Gibbs" 

To: 
Sent: Friday, May 27, 2016 6:26 PM
Subject: Weird cross-contamination between two fossil repositories (and not 
even talking to server!)




Hi,

I've just had a very, very odd experience with fossil.  I'm running 
version 1.34.


Let me first explain what I have done.

I cloned a respository off our server.  I then went into the clone's web 
UI and disabled the auto-sync feature.  I then made 7 commits, the first 
of which caused a trunk fork which I then "repaired" by branching the old 
tip-of-trunk that caused the fork.  I then committed two commits to the 
new branch, then realised that I'd committed the wrong code, so shunned 
the last two commits, rebuilt the respository, unshunned the sha1 
signatures, rebuilt, then recommitted the last two commits using the 
correct code.


Ok, a little complicated but nothing too out-of-the-ordinary, I hope.

Except ... now I have two utterly random commits in my cloned repository - 
both seemingly from the sqlite repository:


2014-12-09 [f66f7a17b7] Version 3.8.7.4 (user: drh, tags: release, 
version-3.8.7.4)

2011-05-19 [ed1da510a2] Version 3.7.6.3 release candidate 1. (user: drh)

Now, it is true that I have a clone of the sqlite respository on my server 
too ... but I haven't yet synced with the server.  Absolutely no server 
communication has happened since my initial clone.  And these odd 
artifacts were definitely not there (or, rephrased, definitely not 
showing) when I was mid-way through all of this work, and are not there on 
the server's copy of the repository either.


Unfortunately, I cannot say exactly when these artifacts appeared, but my 
hunch would be somepoint around the shunning/rebuilding process?  Does 
this even make sense?!?


Worse, I am left not sure whether to simply shun the two random artifacts 
and then push the changes to the repository up to the server.  It has 
taken the best part of a day to get all these commits in and it represents 
about 6GB of source files (the repository has doubled from ~700 MB to ~1.5 
GB) requiring a lot of manual "fossil mv"s to synchronise many moved files 
(fossil doesn't yet support a git-like auto-mv-detection sadly).


Any idea how I can easily check the validity of my repository?  I have 
done the obvious which is to check out each of the recent check-ins and 
compare them with the original source folders, but what I don't know is 
whether the structure of my respository is damaged in some way...


Help :o)

Thanks!
Andy



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

[fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Andy Gibbs]

Hi,

I've just had a very, very odd experience with fossil.  I'm running version 
1.34.


Let me first explain what I have done.

I cloned a respository off our server.  I then went into the clone's web UI 
and disabled the auto-sync feature.  I then made 7 commits, the first of 
which caused a trunk fork which I then "repaired" by branching the old 
tip-of-trunk that caused the fork.  I then committed two commits to the new 
branch, then realised that I'd committed the wrong code, so shunned the last 
two commits, rebuilt the respository, unshunned the sha1 signatures, 
rebuilt, then recommitted the last two commits using the correct code.


Ok, a little complicated but nothing too out-of-the-ordinary, I hope.

Except ... now I have two utterly random commits in my cloned repository - 
both seemingly from the sqlite repository:


2014-12-09 [f66f7a17b7] Version 3.8.7.4 (user: drh, tags: release, 
version-3.8.7.4)

2011-05-19 [ed1da510a2] Version 3.7.6.3 release candidate 1. (user: drh)

Now, it is true that I have a clone of the sqlite respository on my server 
too ... but I haven't yet synced with the server.  Absolutely no server 
communication has happened since my initial clone.  And these odd artifacts 
were definitely not there (or, rephrased, definitely not showing) when I was 
mid-way through all of this work, and are not there on the server's copy of 
the repository either.


Unfortunately, I cannot say exactly when these artifacts appeared, but my 
hunch would be somepoint around the shunning/rebuilding process?  Does this 
even make sense?!?


Worse, I am left not sure whether to simply shun the two random artifacts 
and then push the changes to the repository up to the server.  It has taken 
the best part of a day to get all these commits in and it represents about 
6GB of source files (the repository has doubled from ~700 MB to ~1.5 GB) 
requiring a lot of manual "fossil mv"s to synchronise many moved files 
(fossil doesn't yet support a git-like auto-mv-detection sadly).


Any idea how I can easily check the validity of my repository?  I have done 
the obvious which is to check out each of the recent check-ins and compare 
them with the original source folders, but what I don't know is whether the 
structure of my respository is damaged in some way...


Help :o)

Thanks!
Andy

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