Re: [fossil-users] --nosync option for merge, update, checkout when disconnected

[John P. Rouillard]

In message 

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] --nosync option for merge, update, checkout when disconnected

[Richard Hipp]

On 5/30/16, John P. Rouillard  wrote:
>
> Does it make sense to follow the checkin model for merge/up?
>

Yes it does.

But I'm kinda busy with more urgent matters right this moment.  Do you
have patches?

-- 
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] --nosync option for merge, update, checkout when disconnected

[John P. Rouillard]

Hello Everybody:

I a usually use a central repo with autosync enabled. However
sometimes I want to work from a coffee shop or somewhere else where my
central repo is unavailable.

Similar to what was discussed recently, I need to merge or update my
working area for testing, reporting or just normal work.

Since I am disconnected from my central repo, the pull requests for
merge and update fail and prevent me from using those commands until I
turn off autosync.

While merge/update fail, checkin asks if I want to continue even though the
sync will fail:

  fossil ci --branch test -m "testing checkin"
  Autosync:  http://user@host/fossil/roundup_2
  getaddrinfo() fails: Name or service not known
  Pull done, sent: 0  received: 0  ip:
  Autosync failed.
  continue in spite of sync failure (y/N)?

If I say yes, the checkin to my local repo works.

Does it make sense to follow the checkin model for merge/up?

Alternatively is there some argument I can use for the "pulling"
commands. E.G. a hypothetical --nosync option to turn:

  $ fossil up jquery_1.12.4_upgrade
  Autosync:  http://user@host/fossil/roundup_2
  getaddrinfo() fails: Name or service not known
  Pull done, sent: 0  received: 0  ip:
  Autosync failed.
  Cannot proceed with update

into:

  $ fossil up --nosync jquery_1.12.4_upgrade
  REMOVE fo
  --
  updated-to:   
  changes:  1 file modified.
  "fossil undo" is available to undo changes to the working checkout.

While I can use 'fossil settings autosync 0' there is a good chance I
will forget to turn it on and not notice the next time I up/merge.

Suggestions?

AtDhVaAnNkCsE

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.


___
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] multiple open leaf on closed branches?

[Joerg Sonnenberger]

On Mon, May 30, 2016 at 11:49:47AM -0400, Richard Hipp wrote:
> On 5/30/16, Luca Ferrari  wrote:
> > Hi all,
> > I suspect I did not get right the multiple open leaf warning:
> >
> 
> Maybe the LEAF table in the database file is somehow out of sync.
> Have you tried running "fossil rebuild" to see if that clears the
> problem?

Or the more light-weight "fossil leaves --recompute" for starters.

Joerg
___
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] multiple open leaf on closed branches?

[Richard Hipp]

On 5/30/16, Luca Ferrari  wrote:
> Hi all,
> I suspect I did not get right the multiple open leaf warning:
>

Maybe the LEAF table in the database file is somehow out of sync.
Have you tried running "fossil rebuild" to see if that clears the
problem?

-- 
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] multiple open leaf on closed branches?

[Luca Ferrari]

Hi all,
I suspect I did not get right the multiple open leaf warning:

% fossil stat
...
checkout: fc75337a991c9a1156735b1eca3f9cdd0d2ca70f 2016-05-30 15:25:09 UTC
parent:   e7c2399f591e36e1ec947dfb7b034b2c02697b4b 2016-05-30 12:37:08 UTC
tags: trunk
...
WARNING: multiple open leaf check-ins on trunk:
  (1) 2016-05-30 15:25:09 [fc75337a99] (current)
  (2) 2015-11-19 14:08:50 [aa9521ccd9]
  (3) 2015-08-26 08:18:19 [c413c4592a]

Now, if I go to the 2015-08-26 timeline I see a merge of a branch that
has been integrated (it shows up as closed):

% fossil info c413c4592a
uuid: c413c4592a084187b92b37a0ec000af5b9e09a8f 2015-08-26 08:18:19 UTC
parent:   d0fcfd18f5d1873bbe2175c81119ae8cb0353287 2015-08-25 09:03:40 UTC
merged-into:  f1fba691939b4323ad24771598713861c61c496e 2015-08-26 08:19:45 UTC
tags: trunk, TEST_03092015

The same for the other open leaf.
What is fossil telling me then?

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