[fossil-users] Improved Git import

[Isaac Jurado]

 the Linux kernel repository as
a test, think twice.

Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] how to find a delta manifest?

[Isaac Jurado]

On Sun, Aug 18, 2013 at 1:59 PM, Stephan Beal  wrote:
> On Sun, Aug 18, 2013 at 10:53 AM, Isaac Jurado  wrote:
>>
>> It's about backwards compatibility.  Fossil will not generate delta
>> manifest on commit unless there already are delta manifest on the
>> repository or you force it on the command line.
>
>
> i had no idea there was a --delta option to commit - thanks for that tip.
>
>> I guess that almost all Fossil binaries in use now understand B cards,
>> but as no one has committed to the Fossil repository with the
>> "--delta" option yet, you will not find any delta manifest in it.
>
>
> i don't want to be the first one to try ;), but i will use it on my the
> libfossil repo for testing.
>
>>
>> Delta manifests are quite interesting because they follow the same
>> design concepts as Mercurial's delta storage.  I have already
>> mentioned it, but I have a Fossil branch that can generate delta
>> manifests on import.  However, I still don't have any place to publish
>> it.
>
>
> i don't yet understand the benefit of a delta manifest except that they save
> a few hundred (or thousand) lines of F-cards.
>
> Do you know if it's possible to have a delta of a delta, or is a delta
> always from a non-delta manifest? Parts of the code treat them as if there
> can be any number of them (recursive cleanup in manifest_destroy()), but
> some parts seem to imply that a delta cannot derive from a delta
> (manifest_file_next()).

As far as I've seen, delta manifest cannot be chained.  There is a
formula in the commit code that determines if a delta manifest is
worth using or not.  Therefore, when the parent of a delta manifest is
also a delta manifest, it will contain the F cards from the parent,
plus its own.

> If you have a repo with deltas, may i have a copy of it? It would be very
> useful for testing my delta manifest code.

I tested my improved import branch with the Django git repository,
which turned out contain a couple of very interesting cases I wasn't
even aware of when developing the first patches.  These imported
repositories weight almost 200MB, so I think it is better that I
manage to publish my branch so you can import whatever you want.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] how to find a delta manifest?

[Isaac Jurado]

On Sat, Aug 17, 2013 at 8:36 PM, Stephan Beal  wrote:
>
> On Sat, Aug 17, 2013 at 6:50 PM, Stephan Beal  wrote:
>>
>> http://core.tcl.tk/tcl/artifact/5f37dcc36468eaa8
>
>
> i deconstructed the fossil repo and found not a single B card(!). i aborted 
> the deconstruct of the tcl repo at 11% and already had 9521 one of them.
>
> What makes tcl so special in this regard?

It's about backwards compatibility.  Fossil will not generate delta
manifest on commit unless there already are delta manifest on the
repository or you force it on the command line.  The TCL repository
was probably converted with a Fossil version that had delta manifest
support.

I guess that almost all Fossil binaries in use now understand B cards,
but as no one has committed to the Fossil repository with the
"--delta" option yet, you will not find any delta manifest in it.

Delta manifests are quite interesting because they follow the same
design concepts as Mercurial's delta storage.  I have already
mentioned it, but I have a Fossil branch that can generate delta
manifests on import.  However, I still don't have any place to publish
it.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] incomplete documentation?

[Isaac Jurado]

El 09/08/2013 14:18, "Richard Hipp"  escribió:
>
>
>
> On Fri, Aug 9, 2013 at 7:40 AM, Isaac Jurado  wrote:
>>
>> As I understand it, in Fossil, the history is mostly driven by the date
>> and time of the events, whereas in Git and Hg ancestry relationship
>> comes first.  I gues this is one of the reasons of why there typical
>> "log" command is called "timeline" in Fossil; and also why hiding the
>> possibility of altering the commit time, because it would lead to a
>> confusing timeline graph.
>>
>> When I converted an Hg repo that had its history reordered (with "hg
>> histedit"), the resulting Fossil timeline had an arrow pointing
>> downwards which made it look a bit weird.
>
>
> The timeline display in Fossil is date driven.  But the underlying
repository uses ancestry relationships, just like Git and Mercurial.

Sure, I didn't mean otherwise.  What I was trying to explain is that when
using Git or Mercurial one is under the impression that commit dates are
just informative.  However, Fossil's timeline pays more attention to dates.

Of course, all systems properly record ancestry relationships.

> When you have a parent that is younger than its child, we call that a
"time-warp" and it results in a funky backwards arrow on the timeline
display. See http://www.sqlite.org/src/timeline?c=3f30f00a384d&nd for an
example.  Timewarps can be caused, for example, when commits occur on a
system were the system clock is set to the wrong time.
>
> When doing a sync, Fossil compares timestamps on the local and remote
machines and issues a warning if they are misaligned.  The whole point of
that warning is to try to prevent timewarps.
>
> You can get a list of all timewarps in a project by visiting the
/test_timewarps page in the web interface.  There were several timewarps in
the SQLite history (as seen at http://www.sqlite.org/src/test_timewarps)
but most of them have been fixed by adding tags to check-ins that "correct"
their check-in time.  The
http://www.sqlite.org/src/info/cbfe6e9df3check-in, for example, had an
original check-in time of 2009-08-20 09:11:06
but this was adjusted to 2009-08-20 16:11:06 for display purposes using a
tag, specifically the http://www.sqlite.org/src/info/14cc3387df tag.
>
> You could, in theory, generate timewarps in Git too, since each check-in
has a timestamp, iirc.  Does anybody know what would happen on the GitHub
timeline graph for a Git repository that contains a timewarp?

I can't speak for git, but in Mercurial when examinig the history graph the
dates are secondary. Therefore, time warps are not highligthted and it's up
to the user to check.

Thanks for the other information.
___
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] incomplete documentation?

[Isaac Jurado]

Replying j. van den hoff:
> as a follow up on this (and the response to the original post by drh):
>
> it _is_ bad that options like `--date-override' are not
> comprehensively documented (notably with `commit') since they can be
> important for "normal" users as well. e.g.:
>
> accidentally, I'm just now in the somewhat painful process of
> extracting a subset of files (and their revision history) from a
> rather big/old/messy `hg' repository. the usual route would be to
> use `hg convert' plus a filemap specification to generate a new `hg'
> repository containing only the desired stuff then the rest would be
> easy (hg -> git -> fsl). alas! this strategy does not allow to
> "flatten" the directory tree (in the old repo the files are "way
> down" in some subdir, in the new one they should be at the
> toplevel). retrospective `mv' actions than lead to problems
> with diffing across the renames in fossil (at least this seems to be
> the situation?). there where more problems with renames in the `hg'
> repo not being handled too good in the whole conversion process -- at
> least I could not achieve a satisfactory fossil repo in the end.

I know it is a bit off-topic, but I have a small branch that enhances
the fossil import code a bit.  My motivation was the same: I wanted to
convert some Hg repos via Git but wanted to preserve renames.

In the end I also added an option to generate delta manifests in Fossil,
which reduces the total artifact size (as reported by "dbstat").

The problem is that I haven't found the time to configure a spare
hosting of mine to publish it.  Sending the whole patch set by e-mail
would be rather tedious.  I should have done it a few weeks ago but the
lack of time and motivation just delayed it indefinitely.  If you are
interested on testing, I can find a spot to upload it this weekend.

> so what I did is I wrote a shell script collecting all relevant
> revisions in the `hg' repo, updating in turn to each revision and
> committing the `hg' working copy files to the new `fossil' repo
> directly. and here is the catch: _only_ when using the --date-override
> flag (and knowing that it is there is a prerequisite...) this can work
> sanely by extracting the date from the `hg log' and inserting it
> correctly during the `fossil ci' (instead of ending up with 100
> commits within 10 seconds...)
>
> just wanted to support julian in his opinion, that fossil's CL help
> should strive to be complete. so, please augment information like the
> one in question here if your time allows for this. I believe the user
> base would appreciate this.

As I understand it, in Fossil, the history is mostly driven by the date
and time of the events, whereas in Git and Hg ancestry relationship
comes first.  I gues this is one of the reasons of why there typical
"log" command is called "timeline" in Fossil; and also why hiding the
possibility of altering the commit time, because it would lead to a
confusing timeline graph.

When I converted an Hg repo that had its history reordered (with "hg
histedit"), the resulting Fossil timeline had an arrow pointing
downwards which made it look a bit weird.

Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] best practices during a large rewrite

[Isaac Jurado]

On Wed, Aug 7, 2013 at 11:23 PM, Themba Fletcher
 wrote:
> Hi all,
>
> I recently got a contract to rewrite a large (web) application. The
> intent is to transition, at a measured pace, from a large collection
> of hand-written, framework-free php files to a structured setup with a
> nice MVC framework, etc.
>
> So far so good. I've got all the original source in a fossil repo and
> it has a pretty rich history as I've been maintaining this system for
> the last year or so.
>
> Moving this to the framework I've chosen will involve, up front,
> moving every single one of the exisiting source files to a new
> location deeper in the project hierarchy. The files will then be
> slowly replaced as their functionality is added to the new system in
> the appropriate place.
>
> I'd love to be able to do this project with hotfixes continuing on
> trunk as the deployed version evolves and having all of the
> restructuring take place on a super massive "v2" branch, but I'm
> anticipating a few problems:
>
> * Merging updates from trunk to v2 -- cherrypick isn't going to work
> very well when the names don't match anymore, is it?
>
> * What should I expect after I've deleted a file on v2 (having
> replaced its functionality) and then merge back some updates from
> trunk containing a change to that file? Just a plain old merge
> conflict or should I expect and watch for the file to reappear on the
> branch after being previously deleted?
>
> * Anything else you can foresee?

Why cherrypick?  The simplest workflow here is, as you mention, develop
new stuff in a v2 branch and fix bugs in trunk.  The key secret here is
the mantra: merge soon, merge often.

I must admint that I haven't used Fossil long enough but what I would
expect from Fossil is to give me a hard time the first time I merge from
v2 to trunk, and straightforward merges the following times.  Take the
following example:

A   B
trunk  --o--o---o---o
 \   \
v2  ---o---o--o--o--o--o--o---o--o--o--o
   C  DE  F

Assume that D is the first merge and is the hell of a merge.  The next
merge (which joins B and E) will have A as the common ancestor.  So,
unless you hit a bug in Fossil, merge F is only about incorporating the
changes between A and B into the v2 branch.  Merge F then makes B the
common ancestor for the next merge.

The advantage here is that, when v2 is ready for primetime, you just
have to merge v2 into trunk and it should be a trivial merge too.

In short, just follow these rules:

 - Don't cherrypick.

 - Always merge trunk into v2.  That is: checkout v2 and, from there,
   merge trunk.  This way the merge is committed as part of the v2
   branch.  When v2 is finished, proceed inversely.

 - Don't let the trunk with a leaf for too long.  Remember: merge soon,
   merge often.  The v2 branch should host most of the development
   activity, so merges will not be so abundant.

 - Personal advice, use a graphical merge tool (e.g. kdiff3).  Fossil
   can be configured to resolve conflicts with them; otherwise, I
   wouldn't even be writing this.

> Has anyone out there tried a complete project restructuring on a
> branch with any success, or is the default workflow to just spin up
> another repo and synchronize changes by hand? Any other thoughts or
> input?

I have successfully performed some heavy refactorings with this workflow
a couple of times now, but with Mercurial.  As I said, I would expect
Fossil to work the same in this workflow because it is a very simple
one: no criss-cross merges, no cherrypicking and the resulting history
is beautifully clean.

I hope it helps.  Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Unshun: "CSRF attempt" error

[Isaac Jurado]

Replying Isaac Jurado:
>
> Index: src/info.c
> ==
> --- src/info.c
> +++ src/info.c
> @@ -1427,11 +1427,11 @@
>if( !g.perm.Read ){ login_needed(); return; }
>if( rid==0 ) fossil_redirect_home();
>if( g.perm.Admin ){
>  const char *zUuid = db_text("", "SELECT uuid FROM blob WHERE rid=%d", 
> rid);
>  if( db_exists("SELECT 1 FROM shun WHERE uuid='%s'", zUuid) ){
> -  style_submenu_element("Unshun","Unshun", "%s/shun?uuid=%s&sub=1",
> +  style_submenu_element("Unshun","Unshun",
> "%s/shun?accept=%s&sub=1#accshun",
>  g.zTop, zUuid);
>  }else{
>style_submenu_element("Shun","Shun", "%s/shun?shun=%s#addshun",
>  g.zTop, zUuid);
>  }
> @@ -1577,11 +1577,11 @@
>if( !g.perm.Read ){ login_needed(); return; }
>if( rid==0 ) fossil_redirect_home();
>if( g.perm.Admin ){
>  const char *zUuid = db_text("", "SELECT uuid FROM blob WHERE rid=%d", 
> rid);
>  if( db_exists("SELECT 1 FROM shun WHERE uuid='%s'", zUuid) ){
> -  style_submenu_element("Unshun","Unshun", "%s/shun?uuid=%s&sub=1",
> +  style_submenu_element("Unshun","Unshun",
> "%s/shun?accept=%s&sub=1#accshun",
>  g.zTop, zUuid);
>  }else{
>style_submenu_element("Shun","Shun", "%s/shun?shun=%s#addshun",
>  g.zTop, zUuid);
>  }
> @@ -1685,11 +1685,11 @@
>rid = name_to_rid_www("name");
>if( rid==0 ){ fossil_redirect_home(); }
>zUuid = db_text("", "SELECT uuid FROM blob WHERE rid=%d", rid);
>if( g.perm.Admin ){
>  if( db_exists("SELECT 1 FROM shun WHERE uuid='%s'", zUuid) ){
> -  style_submenu_element("Unshun","Unshun", "%s/shun?uuid=%s&sub=1",
> +  style_submenu_element("Unshun","Unshun",
> "%s/shun?accept=%s&sub=1#accshun",
>  g.zTop, zUuid);
>  }else{
>style_submenu_element("Shun","Shun", "%s/shun?shun=%s#addshun",
>  g.zTop, zUuid);
>  }
>
> Index: src/shun.c
> ==
> --- src/shun.c
> +++ src/shun.c
> @@ -133,20 +133,21 @@
>@ 
>@ 
>@ 
>@ 
>@
> +  @ 
>@ Enter the UUID of a previous shunned artifact to cause it to be
>@ accepted again in the repository.  The artifact content is not
>@ restored because the content is unknown.  The only change is that
>    @ the formerly shunned artifact will be accepted on subsequent sync
>@ operations.
>@
>@ 
>@ 
>login_insert_csrf_secret();
> -  @ 
> +  @ 
>@ 
>@ 
>@ 
>@
>@ Press the Rebuild button below to rebuild the repository.  The

I've seen this has been addressed:

http://www.fossil-scm.org/index.html/info/0b51238612

However, I'm not sure if just removing CSRF validation is a good idea,
specially when repository operations are involved.  The patch I proposed
basically replicates the current behaviour of the "Shun" link in the
artifact view to the "Unshun" link.

Cheers.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] Unshun: "CSRF attempt" error

[Isaac Jurado]

On Sun, Jul 28, 2013 at 9:47 PM, Marc Simpson  wrote:
> It seems that unshunning is currently broken. To reproduce:
>
> (1) Create a test repository,
>
>   $ fsl version
>   This is fossil version 1.26 [a60b008f1a] 2013-07-26 15:46:01 UTC
>   $ fsl new tmp.fsl
>   $ mkdir tmp; cd tmp
>   $ fsl open ../tmp.fsl
>   $ touch a
>   $ fsl add a; fsl commit -m a a
>   $ fsl ui
>
> (2) Shun commit 'a' via [Admin > Shunned] in the UI.
>
> (3) Click on the newly shunned artifact and attempt to [Unshun].
>
> Output: "Cross-site request forgery attempt".

A bug indeed.  Here's a possible fix:

Index: src/info.c
==
--- src/info.c
+++ src/info.c
@@ -1427,11 +1427,11 @@
   if( !g.perm.Read ){ login_needed(); return; }
   if( rid==0 ) fossil_redirect_home();
   if( g.perm.Admin ){
 const char *zUuid = db_text("", "SELECT uuid FROM blob WHERE rid=%d", rid);
 if( db_exists("SELECT 1 FROM shun WHERE uuid='%s'", zUuid) ){
-  style_submenu_element("Unshun","Unshun", "%s/shun?uuid=%s&sub=1",
+  style_submenu_element("Unshun","Unshun",
"%s/shun?accept=%s&sub=1#accshun",
 g.zTop, zUuid);
 }else{
   style_submenu_element("Shun","Shun", "%s/shun?shun=%s#addshun",
 g.zTop, zUuid);
 }
@@ -1577,11 +1577,11 @@
   if( !g.perm.Read ){ login_needed(); return; }
   if( rid==0 ) fossil_redirect_home();
   if( g.perm.Admin ){
 const char *zUuid = db_text("", "SELECT uuid FROM blob WHERE rid=%d", rid);
 if( db_exists("SELECT 1 FROM shun WHERE uuid='%s'", zUuid) ){
-  style_submenu_element("Unshun","Unshun", "%s/shun?uuid=%s&sub=1",
+  style_submenu_element("Unshun","Unshun",
"%s/shun?accept=%s&sub=1#accshun",
 g.zTop, zUuid);
 }else{
   style_submenu_element("Shun","Shun", "%s/shun?shun=%s#addshun",
 g.zTop, zUuid);
 }
@@ -1685,11 +1685,11 @@
   rid = name_to_rid_www("name");
   if( rid==0 ){ fossil_redirect_home(); }
   zUuid = db_text("", "SELECT uuid FROM blob WHERE rid=%d", rid);
   if( g.perm.Admin ){
 if( db_exists("SELECT 1 FROM shun WHERE uuid='%s'", zUuid) ){
-  style_submenu_element("Unshun","Unshun", "%s/shun?uuid=%s&sub=1",
+  style_submenu_element("Unshun","Unshun",
"%s/shun?accept=%s&sub=1#accshun",
 g.zTop, zUuid);
 }else{
   style_submenu_element("Shun","Shun", "%s/shun?shun=%s#addshun",
 g.zTop, zUuid);
 }

Index: src/shun.c
==
--- src/shun.c
+++ src/shun.c
@@ -133,20 +133,21 @@
   @ 
   @ 
   @ 
   @ 
   @
+  @ 
   @ Enter the UUID of a previous shunned artifact to cause it to be
   @ accepted again in the repository.  The artifact content is not
   @ restored because the content is unknown.  The only change is that
   @ the formerly shunned artifact will be accepted on subsequent sync
   @ operations.
   @
   @ 
   @ 
   login_insert_csrf_secret();
-  @ 
+  @ 
   @ 
   @ 
   @ 
   @
   @ Press the Rebuild button below to rebuild the repository.  The


Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Unshun: "CSRF attempt" error

[Isaac Jurado]

On Mon, Jul 29, 2013 at 4:03 PM, Warren Young  wrote:
> On 7/28/2013 13:47, Marc Simpson wrote:
>>
>>
>> Output: "Cross-site request forgery attempt".
>
>
> That's a browser-specific feature, not something Fossil does.  It may
> be that Fossil could work differently to avoid triggering this browser
> security feature, but ultimately it's a false positive.

Please, don't mislead other people.  CSRF is a Web vulnerability that
Browsers can't prevent yet.  So it is normally handled on the server
side.  Check Fossil's sources (src/login.c):

/*
** Before using the results of a form, first call this routine to verify
** that this Anti-CSRF token is present and is valid.  If the
Anti-CSRF token
** is missing or is incorrect, that indicates a cross-site scripting attach
** so emits an error message and abort.
*/
void login_verify_csrf_secret(void){
  if( g.okCsrf ) return;
  if( fossil_strcmp(P("csrf"), g.zCsrfToken)==0 ){
g.okCsrf = 1;
return;
  }
      fossil_fatal("Cross-site request forgery attempt");
}

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] how to delete old history?

[Isaac Jurado]

On Wed, Jul 24, 2013 at 4:21 PM, Steve Landers
 wrote:
>
> On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:
>
>> AFAIK git offers a mechanism for changing history, but Fossil doesn't like 
>> for history to change.
>
> It isn't changing history, it is setting a subproject free to live
> it's own life. That's not an unusual situation, given that projects
> often grow and then divide.
>
> So I detach a local repository, rename it, and continue with a new
> repository for the subproject. But it contains all of the history for
> the parent project, as does the parent project repository.  I can push
> that to a branch and close it in the detached repo, no big deal.  But
> it isn't ideal, especially if the original repo is large.
>
> Being able to detach based on a specific commit or branch would be
> nice (not essential, but nice).

That looks like a Fossil to Fossil export/import feature, without having
to go through Git fast-export format, right?

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała  wrote:
> Hi all,
>
> My 2 cents below regarding ticket numbering:
>
> 2013/7/22 Stephan Beal 
>>
>>
>>> * built-in persistent integer ticket numbers in addition to the SHA1
>>> ticket/artifact ID.  The SHA1 hexdigest fragments are too geeky for
>>> management during the weekly status meeting.
>>
>>
>> Stable incremental numbers are literally not possible to solve for
>> DCVS systems, which is why the SHA's (geeky/unwieldy as they are) are
>> used.
>
> I wrote some time ago about this as I think you can have a simple,
> relatively easy to grasp ticket numbering in DCVS (not integer
> though). It involves three simple steps:
>
> - project create initializes internal repo ticket number with '1',
> - project clone adds suffix '.1' to the repo ticket number,

Like this?

Origin: 1
Clone Origin to A: 1.1
Clone Origin to B: 1.2
Clone A to C: 1.1.1
Clone A to D: 1.1.2
Clone B to E: 1.2.1
Clone B to F: 1.2.2

A creates ticket: 1.1.1
B creates ticket: 1.2.1

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 1:30 PM, Stephan Beal  wrote:
>
>>   - Ensuring API/ABI compatibility is harder.  And this actually
>> slows down development because new features have to be
>> implemented
>
> i don't envision us having to work about this.  Fossil is not a
> library with the same uses as, say, sqlite3. If we have to concern
> ourselves with this level of compatibility then fossil has probably
> gotten more popular than i expected.  In any case, i do not envision
> most people using the library - they will have a single binary (built
> on top of the library).  The library would be there so that fossil can
> finally be integrated into places like IDEs.

I'm sorry but I find this a bit confusing.  If you want to offer a
library where programs can link into, what difference does it make by
assuming it will have a small and concrete set of users?  That code will
need maintenance too, and a compatibility compromise if often necessary
for practical reasons.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado  wrote:
>
>   - Ensuring API/ABI compatibility is harder.  And this actually slows
> down development because new features have to be implemented

Sorry, incomplete sentence:

New features would have to be implemented in the library first and
then exposed.  That's 150% development overhead.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 12:28 PM, Stephan Beal  wrote:
> On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi 
> wrote:
>>
>> Would using something similar to Vim's mechanism (allowing Fossil to
>> be compiled with Lua/Ruby/MZScheme/Python/etc. support) be more
>> acceptable?
>
>
> If the core library has a sane interface, there's no reason we can't
> have ALL of those bindings - they just need to be implemented by
> someone. For example, as soon as fossil has a library API, i will
> certainly write a binding for it for my own personal scripting
> language (not because the world needs it, but because that's the type
> of thing i do in my free time), and being able to implement such
> bindings will be a point i focus on when designing any fossil library
> interface.

Converting Fossil into a library has a lot of downsides:

  - Building a library in a platform-independent manner is non-trivial
(unless making use of things such as libtool or CMake is alright).

  - A lot of additional code has to be added to avoid being tricked by
users passing incorrect parameters.

  - Testing is more tedious; test code needs to be developed in C to
ensure the calls work.  Unless the test code can be generated
automatically through a scripting language, which is not simple
either.

  - Ensuring API/ABI compatibility is harder.  And this actually slows
down development because new features have to be implemented

  - Sooner or later, a useful library has to match the following
requirements:

  * Re-entrant
  * Thread-safe
  * Support both synchronous and asynchronous remote operations
  * Friendly to bindings

To match the previous requirements, designs can be come very
baroque, and therefore, harder to read and maintain.

  - A thorough documentation would be necessary.

But, the worst of all, is that even if the library is greande-proof, you
would be indirectly hit by bugs in external software using it.

Even Git, with its humongous manpower, has struggled a couple of years
to make an incomplete library.

I'd suggest the Mercurial approach: focus on the JSON API and offer it
over multiple transports (HTTP, SSH, UNIX sockets, pipes).  Then let
anybody interested on integrating develop a client in their language of
choice.  Because JSON has first-class support in almost any computer
language, bindings would not be necessary and the current process model
could be kept.

Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Problem Importing From Git

[Isaac Jurado]

On Fri, Jul 12, 2013 at 12:24 AM, Aaron W.Hsu  wrote:
>
> I have a Git fast-export that comes in at around 322MB in size or
> thereabouts. I am running the Windows version of Fossil from 2013-06.
> I run the following from within PowerShell and get some funny output:
>
> C:\...> git fast-export --all | fossil import --git blah.fossil
> ]ad fast-import line: [AGS} -fPIC -shared -o $@ $<
>
> That ]ad line seems to be incorrect, as at the end of it I get no
> blan.fossil file. Can anyone tell me what I am doing wrong here?

I've checked the code again, and found out two things:

  1. The error message is mangled because it contains a CR character at
 the end (harmless bug).

  2. The only situation that, I think, leads to this error is a badly
 formatted, badly interpreted or mangled "data" command.  That is,
 the number of bytes declared do not match the actual content bytes.

Both of which make me suspicious about an automatic line-ending
conversion going on (LF to CRLF most likely).  What I don't really know
is who to blame.

Here are some more tests you can do to help the diagnosis:

  - Does the error happen quickly or it takes a while to show up?

  - Try the conversion WITHOUT a pipeline.  That is:

  git fast-export --all >my_export
  fossil import --git blah.fossil my_export

Note the absence of redirection in the second command.

  - Take a look at the "my_export" file with a text editor or a pager
looking for the same string ("${CFLAGS} -fPIC -shared -o $@"), then
scroll back until you find a line that starts with "data " followed
by a number.

Then, extract the content from the "data" line until the end of the
content (i.e. the whole contents of that particular version of your
Makefile) and calculate its size in bytes.  If I'm correct the size
of the Makefile content should approximately match:

content_size = reported_size + linecount_in_content

Once this behaviour is confirmed, the next step is to look out for
guilty parties ;-)

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Problem Importing From Git

[Isaac Jurado]

El 18/07/2013 20:53, "Aaron W.Hsu"  escribió:
>
> [snip]
>
> I hope this helps! I am not sure which line contributes to the failed
import.

I forgot to ask earlier but, do you have non-latin filenames or some
textual content.

I'm asking because git generates octal escaped sequences (\154) for
non-ascii characters in filenames; which Fossil doesn't currently support
(patch will be published this weekend).

Stay tuned ;-)
___
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] Diff doesn't appear correct with incremental import

[Isaac Jurado]

On Mon, Jul 15, 2013 at 3:21 PM, Sean Woods  wrote:
>
>> This all works fine, with one significant exception.  When I do a
>> diff operation on many files that are updated during the incremental
>> import, it appears that the entire file is "new."  In other words,
>> the left hand side of the diff is blank and the right hand side is
>> entirely green.  If I do a unified diff, the entire screen is green.
>> I look at the patch, and it's filed with plus signs.  Etc.
>
> Just wondering if anyone else had ideas about this issue.  Perhaps I'm
> not interpreting the meaning of "incremental" properly?  I checked the
> src/import.c code in the fossil repository but will need to do a
> little more digging to really understand what's going on (need to
> study up on fossil repository structure, etc).
>
> Any guidance or impressions would be greatly appreciated.

I've been patching the import code on my little spare time and, from
what I've seen, I'm under the impression that incremental import is not
supported.

So, I believe that the "--incremental" option of the import command is a
bit misleading.  The only thing it does is to open an existing SQLite
database without complaining.

The problem with incremental imports is the SHA1 hash mapping between
git and Fossil:  in the pure content case (blobs) they may be the same,
but the correspondence between git commits and manifest artifacts is not
currently saved anywhere.  I don't think it should be too much difficult
to do though, because every other version control system does it.

If you have some patience, I may take a look at it once I finish testing
my import patches that generate delta manifests.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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 Repository with remote users

[Isaac Jurado]

El 11/07/2013 17:52, "Trachta, Nathan [USA]" 
escribió:
>
> Hi,
>
>
>
> I’m looking at using Fossil as a CM tool.  Because of our systems I’m
looking at having a stand-alone Fossil repository with remote users who
need to have access to clones of the repository.  This means the remote
users will be sent a copy of the clone and have to send their updates.  Is
there anything special about this I need to know?

By default, Fossil works in "autosync" mode.  So, each modification of a
cloned repository will be followed by a sync operation, automatically.

Each clone, however, is free to disable this behavior and work in a fully
disconnected manner, having to sync manually when desired.
___
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] Problem Importing From Git

[Isaac Jurado]

El 12/07/2013 00:28, "Aaron W.Hsu"  escribió:
>
> I have a Git fast-export that comes in at around 322MB in size or
thereabouts. I am running the Windows version of Fossil from 2013-06. I run
the following from within PowerShell and get some funny output:
>
> C:\...> git fast-export --all | fossil import --git blah.fossil
> ]ad fast-import line: [AGS} -fPIC -shared -o $@ $<

Could you locate that line at the export code and provide some context
around it?  For example, the ":mark" lines before and after?

That should help narrow down the problem.

> That ]ad line seems to be incorrect, as at the end of it I get no
blan.fossil file. Can anyone tell me what I am doing wrong here?

I think all the import process is wrapped in a DB transaction, so its all
or nothing if an error occurs.

Regards.
___
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] Why delta manifests?

[Isaac Jurado]

On Mon, Jul 1, 2013 at 9:44 PM, Joerg Sonnenberger
 wrote:
> On Mon, Jul 01, 2013 at 05:18:40PM +0200, Isaac Jurado wrote:
>> On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger
>> > Delta manifests are not meant to reduce the repository size, but the
>> > amount of parsing to be done.
>>
>> That sounds intriguing.  What kind of operations can complete without
>> having to load the baseline manifest at all?
>
> There are primarily two uses. To find out what artifacts represent
> control manifests, you have to check them for well-formedness. That
> means that rebuild is a direct function of the raw, undeltafied size
> of the repository. Second, you can compute changes between two
> manifests that use the same base line directly. Third, it cuts the
> delta chain depth a lot as well.

I didn't think about deep delta chains, thanks :-)

So I take that delta manifests are a good thing to have.  Therefore,
I'll keep working on my patch to generate delta manifests from import.

Thank you for the information.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Why delta manifests?

[Isaac Jurado]

On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger
 wrote:
> On Mon, Jul 01, 2013 at 12:08:42AM +0200, Isaac Jurado wrote:
>> After the results, the conclusion is obvious: the generic artifact delta
>> compression is outperforming the delta manifest convention.
>>
>> So the question is, what is the rationale behind delta manifests?
>> After checking Fossil's history, it looks like they were added after
>> artifact delta compression.  Which actually seems even more
>> confusing.
>
> Delta manifests are not meant to reduce the repository size, but the
> amount of parsing to be done.

That sounds intriguing.  What kind of operations can complete without
having to load the baseline manifest at all?

Cheers.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Why delta manifests?

[Isaac Jurado]

Hello all,

I've been working further on improving the import command.  This time I
played with the generation of delta manifests with the same heuristic
used by the commit command.

But, after comparing with and without delta manifests, I noticed that
even though the total raw size of the artifacts was indeed reduced, the
real disk size was not.

After the results, the conclusion is obvious: the generic artifact delta
compression is outperforming the delta manifest convention.

So the question is, what is the rationale behind delta manifests?  After
checking Fossil's history, it looks like they were added after artifact
delta compression.  Which actually seems even more confusing.

Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Importing moderately sized repositories

[Isaac Jurado]

I'm playing with ways to easily reduce the tame it takes to import a
moderately sized repository (around 50MB in git).

My first attempt looks like this:

Index: src/import.c
==
--- src/import.c
+++ src/import.c
@@ -731,10 +731,11 @@
   char *zPassword;
   FILE *pIn;
   Stmt q;
   int forceFlag = find_option("force", "f", 0)!=0;
   int incrFlag = find_option("incremental", "i", 0)!=0;
+  int fastFlag = find_option("fast", 0, 0)!=0;
 
   find_option("git",0,0);  /* Skip the --git option for now */
   verify_all_options();
   if( g.argc!=3  && g.argc!=4 ){
 usage("REPOSITORY-NAME");
@@ -749,10 +750,18 @@
 if( forceFlag ) file_delete(g.argv[2]);
 db_create_repository(g.argv[2]);
   }
   db_open_repository(g.argv[2]);
   db_open_config(0);
+
+  if( fastFlag ){
+db_multi_exec(
+"PRAGMA journal_mode=OFF;"
+"PRAGMA synchronous=OFF;"
+"PRAGMA temp_store=MEMORY;"
+);
+  }
 
   /* The following temp-tables are used to hold information needed for
   ** the import.
   **
   ** The XMARK table provides a mapping from fast-import "marks" and symbols

However, it doesn't seem to make much difference.  Is there any other
SQLite tunable that can improve performance even at the cost of
resistance to hardware failure?

Thanks in advance.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] ticket: binary problems on Mac?

[Isaac Jurado]

On Fri, Jun 28, 2013 at 8:00 PM, j. van den hoff
 wrote:
> On Fri, 28 Jun 2013 19:31:01 +0200, Stephan Beal 
> wrote:
>
>> Can anyone confirm/deny/elaborate on:
>>
>>
>> http://www.fossil-scm.org/index.html/tktview/bf142968a8db271fb13cf46b715af9ebaad59f44
>
>
> just tested it: yes, I can confirm the problem, although the error message
> is slightly different here:
>
> 8<---
> dyld: Library not loaded: /opt/local/lib/libreadline.6.1.dylib
>   Referenced from: /Users/vdh/Desktop/fossil
>   Reason: no suitable image found.  Did find:
> /opt/local/lib/libreadline.6.1.dylib: mach-o, but wrong architecture
> Trace/BPT trap
> 8<
>
> also, I see this for the first time. I'm currently using fossil version 1.25
> [878f7008ab] 2013-05-31 17:41:25 UTC
> (compiled from source) which just works fine.
>
> otherwise I can only provide the following bits of information:
>
> 1.
> `/opt/local' is the location used by the (non-Apple) package management
> system Macports (http://www.macports.org/). it's used by many but sure not
> by all mac users. in my case `libreadline.dylib' currently is a softlink to
> libreadline.6.2.dylib, but not libreadline.6.1.dlylib (which apparently what
> fossil is looking for). question is the binary explicitly expecting
> libreadline.6.1 instead of the canonical name libreadline.dylib?
>
> 2.
> a file `libreadline.dylib' is also found in /usr/lib. this should be the
> version 'officially' used by Apple.
>
> naive question: if readline is needed/used by fossil, could the library not
> be linked statically?

For some reason, the libreadline loader reference has an absolute path
instead of relative (or has a modified runtime path).  Searching a bit
took me to this question:

http://stackoverflow.com/questions/4513799/how-to-set-the-runtime-path-rpath-of-an-executable-with-gcc-under-mac-osx

Which could be related.  Maybe a verbose compilation (showing all
compiler and linker flags) could reveal a hint.  But I may also be
wrong, as I'm extrapolating from what I know about ELF binaries, so in
Mach'O may not apply.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Importing git copies and renames

[Isaac Jurado]

Hello,

I finally came up with something to make import work with:

git fast-export -M -C ...

Below is the tentative patch that seems to work on my tests.  The good
thing is that even though Fossil does not follows history across
renames, at least now the rename operation is visible and both source
and destination timelines are now linked.  For repositories imported
from git, that is.

Please accept my apologies if I failed to follow the conventions.
Comments and testing will be very welcomed.


Index: src/import.c
==
--- src/import.c
+++ src/import.c
@@ -107,10 +107,11 @@
   gg.nMerge = 0;
   for(i=0; iisFrom==0 ) continue;
 fossil_free(pFile->zName);
 fossil_free(pFile->zPrior);
+pFile->zPrior = 0;
 fossil_free(pFile->zUuid);
 *pFile = gg.aFile[--gg.nFile];
 i--;
   }
 }else
@@ -651,51 +658,36 @@
   zTo = rest_of_line(&z);
   i = 0;
   mx = gg.nFile;
   nFrom = strlen(zFrom);
   while( (pFile = import_find_file(zFrom, &i, mx))!=0 ){
-if( pFile->isFrom==0 ) continue;
 pNew = import_add_file();
 pFile = &gg.aFile[i-1];
 if( strlen(pFile->zName)>nFrom ){
   pNew->zName = mprintf("%s%s", zTo, pFile->zName[nFrom]);
 }else{
-  pNew->zName = fossil_strdup(pFile->zName);
+  pNew->zName = fossil_strdup(zTo);
 }
 pNew->isExe = pFile->isExe;
 pNew->isLink = pFile->isLink;
 pNew->zUuid = fossil_strdup(pFile->zUuid);
 pNew->isFrom = 0;
   }
 }else
 if( memcmp(zLine, "R ", 2)==0 ){
-  int nFrom;
   import_prior_files();
   z = &zLine[2];
   zFrom = next_token(&z);
   zTo = rest_of_line(&z);
   i = 0;
-  nFrom = strlen(zFrom);
   while( (pFile = import_find_file(zFrom, &i, gg.nFile))!=0 ){
 if( pFile->isFrom==0 ) continue;
-pNew = import_add_file();
 pFile = &gg.aFile[i-1];
-if( strlen(pFile->zName)>nFrom ){
-  pNew->zName = mprintf("%s%s", zTo, pFile->zName[nFrom]);
-}else{
-  pNew->zName = fossil_strdup(pFile->zName);
-}
-pNew->zPrior = pFile->zName;
-pNew->isExe = pFile->isExe;
-pNew->isLink = pFile->isLink;
-pNew->zUuid = pFile->zUuid;
-pNew->isFrom = 0;
-gg.nFile--;
-*pFile = *pNew;
-memset(pNew, 0, sizeof(*pNew));
+pFile->zPrior = pFile->zName;
+pFile->zName = fossil_strdup(zTo);
+pFile->isFrom = 0;
   }
-  fossil_fatal("cannot handle R records, use --full-tree");
 }else
 if( memcmp(zLine, "deleteall", 9)==0 ){
   gg.fromLoaded = 1;
 }else
 if( memcmp(zLine, "N ", 2)==0 ){


-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] Handling renames on import

[Isaac Jurado]

Replying Richard Hipp:
> On Mon, May 27, 2013 at 3:35 PM, Isaac Jurado  wrote:
>
>> Hello,
>>
>> I'm testing Fossil by migrating a bunch of Mercurial repositories.
>> Unlike Git, Mercurial tracks file renames.  However, in order to create
>> a Fossil repository I have to follow the Mercurial -> Git -> Fossil
>> path.
>>
>> On the first conversion I lose file copying/renaming information.  But
>> the "git fast-export" command has the -M and -C switches to enable
>> copy/rename detection heuristics.  Therefore, the last conversion step
>> looks like:
>>
>> git fast-export -M -C --all | fossil import --git ../myrepo.fossil
>>
>> The good news is that the heuristics work, as Fossil fails with the
>> following message:
>>
>> cannot handle R records, use --full-tree
>>
>
> Do you have a git-fast-export output file that you can send me for
> testing purposes (perhaps via private email)?

Well, I've been digging around a bit.  After reading the git-fast-import
man page and doing some experiments, I've discovered the following:

The "R " record has exactly the same syntax as the "C " record.
Therefore, for each file that has been renamed there is a commit record
like:

R old_name new_name

If, apart from a rename, there were changes in the file contents, an
additional "M " record is appended just below the rename.

I'm not really sure about the value and support of file rename in
Fossil for three reasons:

  1. There is no "copy" command
  2. The "mv/rename" command does not actually operate on the
 filesystem, but after the user has performed the operation
  3. This mail:
  http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-July/000325.html

I'm willing to carry on and try to fix this missing import piece, but
only if it is worth the trouble.

Does "mv/rename" improve the delta algorithm and/or file tracking in any
way?

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] Markdown

[Isaac Jurado]

El 29/05/2013 06:28, "Jonathan Otsuka"  escribió:
>
> Downloads are not compiled with --markdown (its still experimental) you
will need to checkout and compile fossil with --markdown yourself.

Beware that --mardown is not a configure option anymore, in trunk, so it
will be enabled by default in future releases.

>
> Jonathan Otsuka
>
> On May 28, 2013, at 10:29 PM, Doug Franklin 
wrote:
>
> > Do the default (downloadable) versions of Fossil not have Markdown
support enabled, or am I doing something wrong?  My browser keeps telling
me "open or save this unknown file type".
> >
> > --
> > Thanks,
> > DougF (KG4LMZ)
> > ___
> > 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
___
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] Code review (reloaded)

[Isaac Jurado]

On Tue, May 28, 2013 at 5:25 PM, Richard Hipp  wrote:
>
> On Tue, May 28, 2013 at 11:05 AM, Laurens Van Houtven <_...@lvh.io> wrote:
>>
>>
>> My question about how this process with the "pending-review" branch
>> works was more about the mechanics of how you'd use such a branch to
>> facilitate code review. What goes in that branch? How does it get
>> there? What is the sequence of fossil commands?
>
>
> You can create the branch as you do the comment.  For example:
>
>  fossil commit --branch pending-review
>
> Or
>
> fossil commit --branch experimental
>
> If you forget to do it then, you can always visit a check-in after it
> is committed and click on the "Edit" link to do things like revise the
> check-in comment, update the check-in time, or move the check-in to a
> different branch (such as "experimental" or "pending-review" or
> "mistake").
>
> Sometimes somebody will check-in a change to trunk that I don't agree
> with.  When that happens, I just move their check-in off into a
> branch.
>
> A tangent:  Note that when you "edit" a check-in, you are not really
> changing the check-in.  You are, instead, adding additional
> information.  Fossil does not erase or modify, it only augments.  The
> original check-in comment, and time, and branch are all still there
> for anybody to see.  By 'editing' the commit, you are adding a new
> record to the repository that says "for display purposes, modify
> checking XYZ as follows..."
>
> Notes also that Fossil allows you to start a new branch named (for
> example) "experimental" even if there already exists one or more other
> branches with the same name.  At
> http://www.fossil-scm.org/fossil/timeline?n=200&r=experimental it
> looks like there are a dozen or more "experimental" branches currently
> in the Fossil tree.

That is very interesting.  How do you achieve the same filtering from
the command line?

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Did you know that Fossil could do...

[Isaac Jurado]

On Tue, May 28, 2013 at 3:08 PM, Richard Hipp  wrote:
>
> Survey:  How many people know that in the web-based timeline for
> Fossil, you can click on any two nodes in the graph and get a diff
> between those two nodes?
>
> I think this is a very useful feature.  But I'm guessing that not many
> people know it exists.  Please confirm or refute my guess.

A colleage discovered it, I'm not sure if by accident or intentionally,
when I sent him a link to the timeline page in the Fossil website.

Then I checked the release notes because it wasn't working with my
build.

> And assuming I'm guessing correctly, do you have any suggestions on
> how I can get the word out about this and other useful but obscure
> features of Fossil?

For the particular case of the selective timeline diffs I guess it would
help adding the following CSS to the commit nodes/boxes:

cursor: pointer

That way people would get a hint that the box is clickable.

For other features, I guess there should be more mentions to the release
notes.  Other projects do that.

Cheers.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Handling renames on import

[Isaac Jurado]

Wow, I didn't expect this attention.  Let me reply in detail.

>>> I'm testing Fossil by migrating a bunch of Mercurial repositories.
>>> Unlike Git, Mercurial tracks file renames.  However, in order to
>>> create a Fossil repository I have to follow the Mercurial -> Git ->
>>> Fossil path.
>>>
>>
>> Is there a better way?  Can we create a direct Hg->Fossil importer?
>
> Seriously - is there a description of the Hg format someplace that is
> sufficient detailed to be able export the repo file?
>
> Note that there is no such description of "git".  There is a format
> description for git-fast-export which is "ok" but not great.

For now it's enough.  Besides, there are only two ways I know of
exporting "changesets" (i.e. commits in Mercurial jargon):

  1. An exported changeset, which looks like a patch with a header.

  2. The wire protocol (or bundle), which I believe has a durable
 format, for backwards compatibility reasons.  However, I still need
 to have a look at it.

On the other hand, there are also two ways of converting from Mercurial
to Git:

  1. Via the fast-export scripts:

 git://repo.or.cz/fast-export.git

  2. By pushing from a Mercurial repo to a Git repository with the aid
 of the hg-git extension:

 http://hg-git.github.io/

Whether we like it or not, Mercurial users have to deail with Git's
network effect so the situation has to be accepted as it is.  Therefore,
I don't think that developing a straight importer from Mercurial is
worth the effort.

>> On the first conversion I lose file copying/renaming information.
>> But the "git fast-export" command has the -M and -C switches to
>> enable copy/rename detection heuristics.  Therefore, the last
>> conversion step looks like:
>>
>> git fast-export -M -C --all | fossil import --git ../myrepo.fossil
>>
>> The good news is that the heuristics work, as Fossil fails with the
>> following message:
>>
>> cannot handle R records, use --full-tree
>>
>> Which would be understandable if it was a completely unsupported
>> caes.  Nevertheless, I searched for the place where the error
>> originates and I found this:
>>
>
> I apparently wrote that particular code.  But if I ever knew what an
> "R" record was, I have now forgotten.  You might try commenting out
> the fossil_fatal() call at the end of that code block to see what
> happens.  If that doesn't work, somebody is going to need to spend a
> day or say reverse-engineering the rename-support in git-fast-export.

Sounds like an interesting challenge.  I'll try to make time this
weekend to take a look.

> Do you have a git-fast-export output file that you can send me for
> testing purposes (perhaps via private email)?

Right now I'm using private code for testing.  But in a day or two I can
look for my published repositories from which I can sure prepare a
similar scenario.

My initial motivation of all this copy and rename issue was to see if
having the rename information would guide or help delta generation and
provide better repository compression.  I have special interest, even a
bit irrational I must admit, in testing how Fossil's repository size
responds to renames as I tend to reorganize code quite often.  Specially
since Mercurial suffers a bit dramatically in most cases.

Thanks for your time.  Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Handling renames on import

[Isaac Jurado]

Hello,

I'm testing Fossil by migrating a bunch of Mercurial repositories.
Unlike Git, Mercurial tracks file renames.  However, in order to create
a Fossil repository I have to follow the Mercurial -> Git -> Fossil
path.

On the first conversion I lose file copying/renaming information.  But
the "git fast-export" command has the -M and -C switches to enable
copy/rename detection heuristics.  Therefore, the last conversion step
looks like:

git fast-export -M -C --all | fossil import --git ../myrepo.fossil

The good news is that the heuristics work, as Fossil fails with the
following message:

cannot handle R records, use --full-tree

Which would be understandable if it was a completely unsupported caes.
Nevertheless, I searched for the place where the error originates and I
found this:

}else
if( memcmp(zLine, "R ", 2)==0 ){
  int nFrom;
  import_prior_files();
  z = &zLine[2];
  zFrom = next_token(&z);
  zTo = rest_of_line(&z);
  i = 0;
  nFrom = strlen(zFrom);
  while( (pFile = import_find_file(zFrom, &i, gg.nFile))!=0 ){
if( pFile->isFrom==0 ) continue;
pNew = import_add_file();
pFile = &gg.aFile[i-1];
if( strlen(pFile->zName)>nFrom ){
  pNew->zName = mprintf("%s%s", zTo, pFile->zName[nFrom]);
}else{
  pNew->zName = fossil_strdup(pFile->zName);
}
pNew->zPrior = pFile->zName;
pNew->isExe = pFile->isExe;
pNew->isLink = pFile->isLink;
pNew->zUuid = pFile->zUuid;
pNew->isFrom = 0;
gg.nFile--;
*pFile = *pNew;
memset(pNew, 0, sizeof(*pNew));
  }
  fossil_fatal("cannot handle R records, use --full-tree");
}else

Then I tried commenting the call to fossil_fatal() and the import
completed, but the old files were not removed.

So, finally, my question is.  What is that code lacking in order to
correctly import copy and rename information?

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] Git import newlines in comments

[Isaac Jurado]

Replying sky5w...@gmail.com:
>
> I am using fossil v1.25[80bf94e0f7] if that might explain further.

Yes, that explains it.  The use of  was
added here:

http://fossil-scm.org/index.html/info/f9d4e0853b6650294117fd08683aa8358983f974

Which is two months after the version you're running.  In your version,
I guess you could try with the ".timelineTableCell" class, although that
will change more than you expect.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding."
  Leonardo da Vinci
___
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] Git import newlines in comments

[Isaac Jurado]

On Mon, May 27, 2013 at 6:36 PM,   wrote:
>
> "On the web interface, all of the commit message are displayed inside of
>   So you can perhaps adjust the
> look of comments to your liking by editing the CSS and without having to
> touch code."
>
> This has been a long time nuisance for me.  Can someone provide a CSS
> example enabling my [CR+LF]'s within the TimeLine comments?
> I prefer this over modifying the code.

You mean, forcing an element to render as preformatted?

.timelineComment {
font-family: monospace;
white-space: pre;
}

Reference:

http://stackoverflow.com/a/9753612/1100958

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Git import newlines in comments

[Isaac Jurado]

On Mon, May 27, 2013 at 2:46 AM, Richard Hipp  wrote:
>
> On Sun, May 26, 2013 at 8:39 PM, Richard Collins 
> wrote:
>>
>> I'm looking at switching a git repository to fossil.
>>
>> I've done an export and import and found that fossil is not showing the
>> newlines from the commit messages.
>>
>> e.g. the commit message
>>
>> Fix slow PDF thumbnail generation
>>
>> Squashed commit of the following:
>> commit 350fe7521e79a914a54ff384b6ca02a66d5ba136
>> Author: Richard Collins
>> ...
>> ...
>>
>> Shows up in the fossil web UI as:
>>
>> Fix slow PDF thumbnail generation Squashed commit of the following: commit
>> 350fe7521e79a914a54ff384b6ca02a66d5ba136 Author: Richard Collins ...
>>
>>
>> Which is not that great for long commit messages. I don't know if newlines
>> are dropped in the import, or if the UI does not htmlize the newlines. Is
>> there a way to get fossil to import/display the newlines?
>
>
> Under the Admin/Timeline menu you can select "Plaintext comments on
> timeline", among other options.

The problem is that the commit message is not shown within  tags,
so even if line feeds are preserved, the browser will discard them as
whitespace.

In my case that's not really an issue (for migrated Mercurial
repositories) but I wonder if introducing markup in commit messages is a
recommended practice around here.

Cheers.

P.S: Apparently, the command line timeline also joins all the message
into a single line.  I still have to look through the code to see if
it's done at commit/import time or just at rendering.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users