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
