Re: [fossil-users] Git Tag comments

[Artur Shepilko]

> --rename-master renames master
> --rename-trunk renames trunk
> We should strive to keep the command line UI sane.

In my opinion, preserving the long-standing default import target
branch as "trunk" is reasonable, whether we change the semantics of
"--rename-trunk" option or not.

The notion of default import target branch dates back to ~2010, back
then it was fixed as "trunk". The "main-branch" Fossil setting was
introduced ~2011 to allow the Fossil trunk branch to be named
otherwise, keeping "trunk" as the default. Yet the "master"=>"trunk"
import mapping stayed fixed till ~2016, when the --rename-trunk import
option was introduced to relax the mapping
Git:"master"=>, which indeed does have an effect of
renaming trunk. Througout, this was backwards compatible and "trunk"
has been remaining the default import target branch.

Git:"master"=>Fossil:"trunk" name mapping is not arbitrary, as we all
understand, so the "magic" indeed has a convenience for users who aim
to move git repo over to Fossil. Maybe printing a message would make
the "magic" mapping fact more explicit.

As for the Git<=>Fossil branch mapping in general, it maybe more
explicitly described via something like "--branch-map master=trunk"
option, or something to that effect.

I'm not sure how thouroughly the Fossil import from Git fast-export
format has been tested, or which specific use-cases it covers. I
guess, one specific area that needs a closer look is branching and
tagging, as these are quite differing between Git and Fossil.
especially in the git fast-import context.

> The git-fast-import format does not support "lightweight" tags, only
> anointed ones.

Git fast-export exports the lightweight tags via "reset" command such
as (Note: there's not date command):
reset refs/tags/
from :mark
___
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] Feature Request: Search Technotes

[Chris Rydalch]

Had some time during lunch, and figured out how to list the tech-notes in
descending order:

$ fossil sqlite3 -R myclone.fossil "SELECT substr(tagname,7), tagxref.rid,
max(tagxref.mtime) FROM tag, tagxref WHERE tagname GLOB 'event-*' AND
tagxref.tagid=tag.tagid GROUP BY 1 ORDER BY mtime DESC"
8d18bf27e9f9ff8b9017edd55afc35701407d418|35502|2457698.34868013
bfdf42305400f6caa441fa816cb89231e90f8c82|22576|2456530.81914164
a1f9f17b603022c2b032bc3b2bff81118fd68d36|12285|2455688.26677552
d6ba73e22bf6ecbac3b6debb47ca2e15d5e63630|9650|2455502.26658565
be8f2f3447ef2ea3344f8058b6733aa08c08336f|9093|2455478.94143519
347871278941bd7ad08b27cde6a7b8f495c1f905|8915|2455475.0283

However I can't seem to use those results as part of the search results.
Where should I look for errors, to track down what I'm overlooking? Is
there a log or a way to turn on debug output? Is it an issue with body()?

Here is what I've got in src/search.c:

  if( (srchFlags & SRCH_WIKI)!=0 ){
db_multi_exec(
  "WITH wiki(name,rid,mtime) AS ("
  "  SELECT substr(tagname,6), tagxref.rid, max(tagxref.mtime)"
  "FROM tag, tagxref"
  "   WHERE tag.tagname GLOB 'wiki-*'"
  " AND tagxref.tagid=tag.tagid"
  "   GROUP BY 1"
  ")"
  "INSERT INTO x(label,url,score,id,date,snip)"
  "  SELECT printf('Wiki: %%s',name),"
  " printf('/wiki?name=%%s',urlencode(name)),"
  " search_score(),"
  " 'w'||rid,"
  " datetime(mtime),"
  " search_snippet()"
  "FROM wiki"
  "   WHERE search_match(title('w',rid,name),body('w',rid,name));"
);
db_multi_exec(
  "WITH technote(uuid,rid,mtime) AS ("
  "  SELECT substr(tagname,7), tagxref.rid, max(tagxref.mtime)"
  "FROM tag, tagxref"
  "   WHERE tag.tagname GLOB 'event-*'"
  " AND tagxref.tagid=tag.tagid"
  "   GROUP BY 1"
  ")"
  "INSERT INTO x(label,url,score,id,date,snip)"
  "  SELECT printf('Tech Note: %%s',uuid),"
  " printf('/technote/%%s',uuid),"
  " search_score(),"
  " 'e'||rid,"
  " datetime(mtime),"
  " search_snippet()"
  "FROM technote"
  "   WHERE search_match('',body('e',rid,NULL));"
);
  }

I've tried placing the technote's db_multi_exec() before and after the
existing one, but it doesn't seem to make a difference (that I can see
anyway).

Thanks!

On Tue, Jan 24, 2017 at 10:37 PM, Richard Hipp  wrote:

> On 1/24/17, Chris Rydalch  wrote:
> >
> > I started by trying to combine them, mainly because I'm not a very good
> > programmer (most of my experience is with Python), and I was thinking
> this
> > would be the easiest way.
> >
>
> I agree that combining tech-notes with wiki seems like the best approach.
>
> --
> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Directory symlinks...

[Martin Gagnon]

On Tue, Feb 14, 2017 at 10:06:34AM -0800, Joe Mistachkin wrote:
> 
> Martin Gagnon wrote:
> >
> > I'm not sure if this protection is necessary, but if it is, it doesn't
> > get triggered if the symlink point directly to "../../dir3/other_ckout"
> > since the "top of a checkout" check only happens for the recursive call.
> > 
> 
> I believe this may be to protect against file system loops?
> 
I don't think so, all the check does is to look for a _FOSSIL_ or a
.fslckout file exist inside the specified directory.

> >
> > I don't know if the top of a checkout *must* be skipped or not, but
> > right now there's something inconsistent with this rule.  
> > 
> 
> I think it's by design.  It does not appear to be directly related to
> the symlinks issues.
> 
True, the same issue happens when doing the "add" on a real directory.
If a subdirectory inside is the top of a checkout, it will be *silently*
skipped.

I've also notice that the "extra" command ignore those "top of checkout"
directories, just like the "add" command.

So my understanding is that those "top of checkout" directory are
ignored during scan, unless they are explicitly specified from command
line. It does make sense to me now.

May be it would be useful to have a verbose mode (-v) on some commands
like "add" and "extra"? In verbose mode, those commands could print
why some files or directory got skipped. Just an idea...

Regards

-- 
Martin G.
___
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] Directory symlinks...

[Joe Mistachkin]

Martin Gagnon wrote:
>
> I'm not sure if this protection is necessary, but if it is, it doesn't
> get triggered if the symlink point directly to "../../dir3/other_ckout"
> since the "top of a checkout" check only happens for the recursive call.
> 

I believe this may be to protect against file system loops?

>
> I don't know if the top of a checkout *must* be skipped or not, but
> right now there's something inconsistent with this rule.  
> 

I think it's by design.  It does not appear to be directly related to
the symlinks issues.

--
Joe Mistachkin @ https://urn.to/r/mistachkin

___
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] Directory symlinks...

[Martin Gagnon]

On Mon, Feb 13, 2017 at 07:10:52PM -0800, Joe Mistachkin wrote:
> 
> Martin Gagnon wrote:
> > 
> > Strange, "fossil add a_dir_symlink" doesn't works for the case #2 on my
> > actual repository, but if I try to reproduce the problem on a brand new
> > repo, everything works.. Probably I hit a strange corner case. I will
> > try to investigate a bit more.. 
> > 
> 
> I've added the 'test-file-environment' command to Fossil to help with
> figuring this stuff out.  Also, it has an --open-config option which
> is useful.
> 

Thanks for this Joe,

I didn't find something wrong using test-file-environment, my real repo
and my test repo show same things.

However, I decide to debug using gdb, and I found the reason why the
"fossil add symlink_dir" fail in my real repo (with case #2). I was able
to reproduce the same on a new test repository.

It happens that the symlink point to a directory containing a directory
that is the top of a checkout:

  Example:

 /dir1/dir2/main_ckout/dir_symlink

 /dir1/dir2/dir3/other_ckout



 where: 
dir_symlink point to:  ../../dir3


Inside add_cmd, vfile_scan(...) is called with "dir_symlink" here:
  http://fossil-scm.org/index.html/artifact?ln=334=f23144d54a286503

Then, since vfile_scan() find "other_ckout" directory inside, it should
normally call himself recursively with "other_ckout" but in this case
"other_ckout" get skipped here:
  http://fossil-scm.org/index.html/artifact?ln=542=f2ac27cd86e8ff0c

 because it is the top of a checkout.

I'm not sure if this protection is necessary, but if it is, it doesn't
get triggered if the symlink point directly to "../../dir3/other_ckout"
since the "top of a checkout" check only happens for the recursive call.

I don't know if the top of a checkout *must* be skipped or not, but
right now there's something inconsistent with this rule. 


Regards

-- 
Martin G.
___
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] scrubbing private branch or feature branches in Fossil

[Gour]

On Tue, 14 Feb 2017 14:06:19 +0100
Gour  wrote:

> Any hint how to get rid of it since it would allow one to have kind of
> supported for 'featured branches' in the Fossil?

It looks that $id in:

fossil tag add --raw --propagate private $id

was not proper since after re-issuing the above cmd, everything seems
fine now and I'm very happy 'discovering' a very handy feature in
Fossil. :-)

> Sincerely,
> Gour

-- 
An intelligent person does not take part in the sources of misery,
which are due to contact with the material senses. O son of Kuntī,
such pleasures have a beginning and an end, and so the wise man does
not delight in them.


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

[fossil-users] scrubbing private branch or feature branches in Fossil

[Gour]

Hello,

after importing Git repo in Fossil, I notice strange behavior, that
since very beginning, Fossil shows two branches: trunk and
refs/heads(master) up to the [d207fdb1c2] commit and after it, there is
only 'trunk' branch up to the CURRENT...see below:

$fossil timeli -n 1000
=== 2017-02-14 ===
10:35:09 [171ff467dc] *CURRENT* biljeg, knjižara (user: gour tags: trunk)
=== 2017-02-13 ===
20:17:45 [7c93118488] bankomat, gimnastika 1/2017, Spar, Mueller, Kaufland, DM, 
ljekarna (user: gour tags: trunk)

[...]
=== 2017-01-02 ===
11:28:03 [b71abb3afc] pražnjenje septičke (user: g...@atmarama.com tags: trunk)
11:17:03 [4fac2abcee] kamata (Erste), donacija (Zdenko & Olga) (user: 
g...@atmarama.com tags: trunk,
 refs/heads/master)
11:17:03 [2c1dee8f7c] kamata (Erste), donacija (Zdenko & Olga) (user: 
g...@atmarama.com tags: trunk)
=== 2017-01-01 ===
15:42:12 [f2c8377e30] ljekarna (user: g...@atmarama.com tags: trunk, 
refs/heads/master)
15:42:12 [4c6452e921] ljekarna (user: g...@atmarama.com tags: trunk)
10:59:38 [d207fdb1c2] donacija, tržnica, voćarna, Konzum (user: 
g...@atmarama.com tags: trunk, refs/heads/master)
10:59:38 [e8fc67eb6e] donacija, tržnica, voćarna, Konzum (user: 
g...@atmarama.com tags: trunk)
=== 2016-12-31 ===
09:00:13 [8dd1c990a5] Metss, kamate, vođenje računa... (user: g...@atmarama.com 
tags: trunk, refs/heads/master)
09:00:13 [cce6fb345f] Metss, kamate, vođenje računa... (user: g...@atmarama.com 
tags: trunk)

[...]

10:23:02 [6e28e8d2a6] adjust some computer-related transactions (user: gour 
tags: trunk, refs/heads/master)
10:23:02 [5c720a947d] adjust some computer-related transactions (user: 
g...@atmarama.com tags: trunk)
10:15:41 [7d1448b3f5] initial import (NG) (user: gour tags: trunk, 
refs/heads/master)
10:15:41 [ae83c30ca8] initial import (NG) (user: g...@atmarama.com tags: trunk)
10:14:47 [984a7e03ca] initial empty check-in (user: gour tags: trunk, 
refs/heads/master)
10:14:47 [eae3edf959] initial empty check-in (user: g...@atmarama.com tags: 
trunk)

Now, considering to get rid of that duplicate branch (refs/heads/master)
I did the following:

fossil tag add --raw --propagate private 984a7e03ca53787e5c16139e849f

in order to convert refs/heads/master branch into private followed by:

fossil scrub --private

So, now there is no longer 'refs/heads/master' branch, but now it shows:


[7d1448b3f5] initial import (NG) (user: gour) (unpublished)

so I wonder why that refsheads/master branch which was converted into
private and scrubbed still shown as 'unpublished'?

Any hint how to get rid of it since it would allow one to have kind of
supported for 'featured branches' in the Fossil?


Sincerely,
Gour

-- 
Many, many births both you and I have passed. I can remember
all of them, but you cannot, O subduer of the enemy!


___
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] Fossil SCGI Server Regression (from 1.36 to 1.37)

[Thomas Bilk]

So I did bisect yesterday and oh wonder, everything worked properly. I
don't know why I had an issue on Sunday but today it works on a new
test server as well as on my production server. So all-clear for the
server --scgi command.

I would like to use the occasion to thank you developers of fossil
again for this magnificent piece of software. I have to use git at
work which is a mess and I am so happy that I can use a good source
control system for all my project. So, thank you again.

Best regards.
Thomas.

> 2017-02-13 0:28 GMT+01:00 Richard Hipp :
>>> I guess there was a regression introduced somewhere between [8b03934e]
>>> and [fb4b87d9].
>>
>> Would you be willing to bisect for us?
>
> Sure. I will report my findings later today.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users