[prev in list] [next in list] [prev in thread] [next in thread]
List: fossil-users
Subject: Re: [fossil-users] Receiving old versions
From: Richard Hipp <drh () sqlite ! org>
Date: 2014-08-30 20:25:40
Message-ID: CALwJ=Mym0q6yDBqZC83gmHxxdr1qYkVc15fWo2g8Qu21ABZ6aA () mail ! gmail ! com
[Download RAW message or body]
On Sat, Aug 30, 2014 at 3:40 PM, Andy Goth <andrew.m.goth@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm working on a project where the first version given to me was far
> from the first version that existed. Having nothing else to go on, I
> used it as the initial check-in of my new Fossil repository.
>
> Now I have been given a few older versions. What's the best way to go
> about putting them into the repository?
>
You can't. Or, at least, you can't link them into the tree of existing
versions. The older version will become a new and independent graph.
The reason is this: Each version has a "parent", the name of which is
included in the manifest. You cannot add this to the manifest after the
fact, since that would change the manifest and manifests are immutable.
One could enhance Fossil to accept a new kind of tag that "changes" the
parent of a check-in. We already have takes like this for changing the
check-in comment and the check-in time. If such a tag existed, you would
be able to add the older check-ins to the repo, then "reparent" what used
to be your root check-in so that it was a child of when of the older
check-ins you just added. But, as of this writing, no "reparent" tag
exists.
>
> I know I can check them in with --allow-older and the --date-override
> options, though this will produce a very funky timeline display. Is
> there a better way?
>
> I could also make a whole new repository with everything committed in
> the right order, but this is error-prone and, frankly, too OCD for my
> liking.
>
> By the way, --date-override is documented for some commands (e.g. tag)
> but not for commit.
>
> - --
> Andy Goth | <andrew.m.goth/at/gmail/dot/com>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUAiiWAAoJELtYwrrr47Y4jesIAOILfX6anlRgkbneiISmjKQx
> xuQgcmsqpof14dGsbCq8LAWaDsKVOMWw0pDefLoJBHVtYpfR5cR7cNkjLGA4WFNl
> HKO8FqYHYjdPto16BMMKFK7paeGtuAernVZvyfsZRtBxAIg+LwdPXwivxBzSkMO4
> RIzGiK86AXtbSCo7fnRyAunPzyFDXxzOeujrgFJfPrxny8WemRh3rVSHjSC1fh33
> FwraAX1wHbVGA026iauOb3YSvunPy6OdsDGZWtqK9S65ZyQQjLJIrL9tWNdufjvF
> XSt94qygfLSC02WkJ4vlWWKZLQtyXlP7To08m/XkQFg46yfDmYSEZm3G1b1H+FE=
> =7rTV
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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
drh@sqlite.org
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, \
Aug 30, 2014 at 3:40 PM, Andy Goth <span dir="ltr"><<a \
href="mailto:andrew.m.goth@gmail.com" \
target="_blank">andrew.m.goth@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
I'm working on a project where the first version given to me was far<br>
from the first version that existed. Having nothing else to go on, I<br>
used it as the initial check-in of my new Fossil repository.<br>
<br>
Now I have been given a few older versions. What's the best way to go<br>
about putting them into the repository?<br></blockquote><div><br></div><div>You \
can't. Or, at least, you can't link them into the tree of existing \
versions. The older version will become a new and independent graph.<br>
<br></div><div>The reason is this: Each version has a "parent", the name \
of which is included in the manifest. You cannot add this to the manifest after the \
fact, since that would change the manifest and manifests are immutable.<br>
<br></div><div>One could enhance Fossil to accept a new kind of tag that \
"changes" the parent of a check-in. We already have takes like this for \
changing the check-in comment and the check-in time. If such a tag existed, you \
would be able to add the older check-ins to the repo, then "reparent" what \
used to be your root check-in so that it was a child of when of the older check-ins \
you just added. But, as of this writing, no "reparent" tag exists.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
I know I can check them in with --allow-older and the --date-override<br>
options, though this will produce a very funky timeline display. Is<br>
there a better way?<br>
<br>
I could also make a whole new repository with everything committed in<br>
the right order, but this is error-prone and, frankly, too OCD for my<br>
liking.<br>
<br>
By the way, --date-override is documented for some commands (e.g. tag)<br>
but not for commit.<br>
<br>
- --<br>
Andy Goth | <andrew.m.goth/at/gmail/dot/com><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
<br>
iQEcBAEBAgAGBQJUAiiWAAoJELtYwrrr47Y4jesIAOILfX6anlRgkbneiISmjKQx<br>
xuQgcmsqpof14dGsbCq8LAWaDsKVOMWw0pDefLoJBHVtYpfR5cR7cNkjLGA4WFNl<br>
HKO8FqYHYjdPto16BMMKFK7paeGtuAernVZvyfsZRtBxAIg+LwdPXwivxBzSkMO4<br>
RIzGiK86AXtbSCo7fnRyAunPzyFDXxzOeujrgFJfPrxny8WemRh3rVSHjSC1fh33<br>
FwraAX1wHbVGA026iauOb3YSvunPy6OdsDGZWtqK9S65ZyQQjLJIrL9tWNdufjvF<br>
XSt94qygfLSC02WkJ4vlWWKZLQtyXlP7To08m/XkQFg46yfDmYSEZm3G1b1H+FE=<br>
=7rTV<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
fossil-users mailing list<br>
<a href="mailto:fossil-users@lists.fossil-scm.org">fossil-users@lists.fossil-scm.org</a><br>
<a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users" \
target="_blank">http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>D. Richard Hipp<br><a \
href="mailto:drh@sqlite.org" target="_blank">drh@sqlite.org</a> </div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic