Re: [fossil-users] State of tkt-hook-change branch
2013/12/16 Jan Nijtmans : > @Joe/Richard: Any reason to hold back merging this to trunk? > > If not, I'm happy to do the merge. No-one objected, so merged to trunk now. Happy Christmas days to all! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil import timestamp mangling
fossil import --git ignores the timezone field on timestamps. I have
this in the fast import dump:
mark :4
author David Given 1309983972 +0100
committer David Given 1309983972 +0100
data 17
Initial checkin.
...but in the fossil repo it actually ends up being:
{
"type":"checkin",
"uuid":"926edebbe40ee63b0323c2e545e984391d4fd6f4",
"isLeaf":false,
"timestamp":1309983972,
"user":"d...@cowlark.com",
"comment":"Initial checkin.\n",
"tags":["trunk"]
}
Note that the value of timestamp matches the unadjusted value from the
fast import dump.
The code from import.c looks like:
secSince1970 = 0;
for(i=i+2; fossil_isdigit(zLine[i]); i++){
secSince1970 = secSince1970*10 + zLine[i] - '0';
}
fossil_free(gg.zDate);
gg.zDate = db_text(0, "SELECT datetime(%lld, 'unixepoch')",
secSince1970);
gg.zDate[10] = 'T';
It's probably easy enough to fix --- parse the following word, convert
to an offset in seconds, and add. On export the emitted timezone is
hard-coded to +, which should be fine given the time is stored in
seconds since epoch.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom
signature.asc
Description: OpenPGP digital signature
___
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 import timestamp mangling
On Fri, Dec 20, 2013 at 10:53 AM, David Given wrote: > fossil import --git ignores the timezone field on timestamps. I have > this in the fast import dump: > > mark :4 > author David Given 1309983972 +0100 > committer David Given 1309983972 +0100 > data 17 > Initial checkin. > Interesting. I would have thought all time stamps in git would, like Fossil, be seconds from the epoch. (It was originally developed by the Linux kernel core team.) ___ 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 import timestamp mangling
On 20/12/13 16:15, Ron Wilson wrote: [...] > Interesting. I would have thought all time stamps in git would, like > Fossil, be seconds from the epoch. (It was originally developed > by the Linux kernel core team.) So would I. I suppose it *is* seconds since epoch... but they don't define which epoch. Here's a tentative fix: http://www.fossil-scm.org/index.html/info/10f9673a25 (Sorry, I accidentally committed to trunk and then had to undo. It'd be nice if 'fossil branch new' would either change the current branch or at the very least print a warning that the current branch hadn't changed.) Looking at the timezone list, it seems to do the right thing, but timezones make my head hurt. Could someone double-check, please? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs." --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ 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 import timestamp mangling
2013/12/20 David Given : > (Sorry, I accidentally committed to trunk and then had to undo. It'd be > nice if 'fossil branch new' would either change the current branch or at > the very least print a warning that the current branch hadn't changed.) In fossil that's not a problem: You can always move the commit to another branch, even after you already committed it. And ... it's a nice excuse to demonstrate the new "hidden-tag" feature. This way it is possible now to move a commit to the "mistake" branch, close it, and hide it, all in a single action. Done that for your commit. If you want to see it, press the "Unhide" button. Regards, Jan Nijtmans ___ 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 import timestamp mangling
On 20/12/13 22:41, Jan Nijtmans wrote: [...] > In fossil that's not a problem: You can always move the commit to > another branch, even after you already committed it. Oh, yeah, I'd forgotten you could do that. Admittedly, I only noticed after I'd done the sync, and wanted to fix things as quickly as possible. [...] > Done that for your commit. If you want to see it, press > the "Unhide" button. Thanks! -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs." --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Parent of the very first checkin?
hg has a concept of the changeset with uuid . This is the empty changeset, and is equivalent to the parent of the very first checkin. Checking out this changeset will give you an empty repository; checking in with this as the parent will give you a new tree, not connected to the old one. I find myself needing to do this in Fossil: both as something I can check out to remove all files from the working directory, and something I can use as a parent so I can create multiple revision trees. AFAIK there's nothing in the Fossil architecture to forbid it --- is there any way I can do this? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs." --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ 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] Parent of the very first checkin?
Every repository as an initial check-in which is empty. But it always has a different SHA1 hash, since it also includes the timestamp from when the repository was created. Example: http://www.fossil-scm.org/fossil/info/a28c83647d And the actual text of the manifest artifact: http://www.fossil-scm.org/fossil/artifact/a28c83647dfa805f On Fri, Dec 20, 2013 at 6:23 PM, David Given wrote: > hg has a concept of the changeset with uuid > . This is the empty changeset, > and is equivalent to the parent of the very first checkin. Checking out > this changeset will give you an empty repository; checking in with this > as the parent will give you a new tree, not connected to the old one. > > I find myself needing to do this in Fossil: both as something I can > check out to remove all files from the working directory, and something > I can use as a parent so I can create multiple revision trees. > > AFAIK there's nothing in the Fossil architecture to forbid it --- is > there any way I can do this? > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ > │ "There does not now, nor will there ever, exist a programming > │ language in which it is the least bit hard to write bad programs." --- > │ Flon's Axiom > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- 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] Parent of the very first checkin?
On 21/12/13 00:05, Richard Hipp wrote: > Every repository as an initial check-in which is empty. But it always has > a different SHA1 hash, since it also includes the timestamp from when the > repository was created. Is it guaranteed that this will only ever be only checkin with no parents? And that all other checkins will have this as an ultimate ancestor? If so, thanks, it's just what I'm looking for. (It'd be nice if it were tagged so it could be found via a symbolic name --- although I suspect that I'm the only person who's asked for this...) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs." --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ 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] Parent of the very first checkin?
On Fri, Dec 20, 2013 at 7:27 PM, David Given wrote: > On 21/12/13 00:05, Richard Hipp wrote: > > Every repository as an initial check-in which is empty. But it always > has > > a different SHA1 hash, since it also includes the timestamp from when the > > repository was created. > > Is it guaranteed that this will only ever be only checkin with no > parents? No such guarantee. Though you will have to do some unsavory things to your repository to get it into a state where this is not true. > And that all other checkins will have this as an ultimate > ancestor? If so, thanks, it's just what I'm looking for. > > (It'd be nice if it were tagged so it could be found via a symbolic name > --- although I suspect that I'm the only person who's asked for this...) > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ > │ "There does not now, nor will there ever, exist a programming > │ language in which it is the least bit hard to write bad programs." --- > │ Flon's Axiom > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- 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] Parent of the very first checkin?
Thus said Richard Hipp on Fri, 20 Dec 2013 19:05:07 -0500: > http://www.fossil-scm.org/fossil/info/a28c83647d Is there a command line option that will find this artifact? I thought perhaps the root:trunk symbolic name would find it, but I was wrong. It finds c06edd231fc15d145a1c96c39b8fecdb79b33523 which is apparently where the current trunk began from a branch. Of course the following works, but I have to guess at the number of artifacts: fossil timeline -n 10 | tail Thanks, Andy -- TAI64 timestamp: 400052b51f20 ___ 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] Parent of the very first checkin?
If I understand what you're looking for (first empty commit?), when I asked this question some time ago, somebody suggested I just tag it myself. Simple solution, Just Works. On Dec 20, 2013 8:54 PM, "Andy Bradford" wrote: > Thus said Richard Hipp on Fri, 20 Dec 2013 19:05:07 -0500: > > > http://www.fossil-scm.org/fossil/info/a28c83647d > > Is there a command line option that will find this artifact? I thought > perhaps the root:trunk symbolic name would find it, but I was wrong. It > finds c06edd231fc15d145a1c96c39b8fecdb79b33523 which is apparently where > the current trunk began from a branch. > > Of course the following works, but I have to guess at the number of > artifacts: > > fossil timeline -n 10 | tail > > Thanks, > > Andy > -- > TAI64 timestamp: 400052b51f20 > > > ___ > 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] Parent of the very first checkin?
How is what you are looking for different from checking out the very first node in your tree, the "initial empty check-in"? I used to do what you are describing quite extensively when I used monotone. But with monotone it was easy to sync a subset of branches or revision trees from one repo to another. In fossil this is not possible. Once the multiple revision trees are in the same repo they cannot be separated using native tools. You could conceivably export and separate in some other tool I suppose. Anyhow, this factor made it impractical for me to keep different trees in the same repo. I'd be curious to hear a description of your methodology. On Fri, Dec 20, 2013 at 4:23 PM, David Given wrote: > hg has a concept of the changeset with uuid > . This is the empty changeset, > and is equivalent to the parent of the very first checkin. Checking out > this changeset will give you an empty repository; checking in with this > as the parent will give you a new tree, not connected to the old one. > > I find myself needing to do this in Fossil: both as something I can > check out to remove all files from the working directory, and something > I can use as a parent so I can create multiple revision trees. > > AFAIK there's nothing in the Fossil architecture to forbid it --- is > there any way I can do this? > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ > │ "There does not now, nor will there ever, exist a programming > │ language in which it is the least bit hard to write bad programs." --- > │ Flon's Axiom > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
