On Sat, 30 Aug 2014 15:03:32 -0500
Andy Goth <andrew.m.g...@gmail.com> wrote:

> Hash: SHA1
> On 8/30/2014 2:40 PM, Andy Goth wrote:
> > Now I have been given a few older versions.  What's the best way to
> > go about putting them into the repository?
> > 
> > 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 cloned my repository and did the above as a test just to see how bad
> it comes out.  Well, it's pretty bad.  Not only is the timeline
> bizarre, the default diffs are unhelpful too.  Diffs are typically
> against the predecessor version, but in this situation, Fossil's
> concept of "predecessor" doesn't match the naïve user expectation.
> Surprise notwithstanding, this is correct behavior in face of the
> time paradox.
> I think my best course of action is to not try to put the old code
> into the repository unless I am given a more complete archive of
> historical versions, at which time it might be worthwhile to rebuild
> the repository with everything put in the right sequence.  Of course
> this blows away all the artifact IDs, but that would be acceptable at
> this stage.
> Let's say I do this, using the oldest known version as the initial
> commit, and everything seems good for a while.  But then someone finds
> an in-between version thought to have been lost.  I would update to
> its predecessor version then check it in with the date override,
> either allowing the fork or putting it on an branch.  The timeline
> would look mostly good, but only because the predecessor version
> already existed. Diffs surrounding the newfound would have to be done
> with explicitly selected from and to versions, but that's a small
> price to pay for not having to rebuild the repository and trash the
> artifact IDs.
> Then a version older than the previously oldest known version is
> found. Now we're in trouble again.
> Maybe I could have prevented that last problem by making the initial
> empty check-in be dated before the project was known to have started,
> so there would never be anything older than it.
> Thoughts?

Can you try to do it "backwards"? (don't know if backwards is the rigth word). 
Create a new repository, import the older source files, pull from your 
repository. Don't sync or your repository will become fluffed.

> - -- 
> Andy Goth | <andrew.m.goth/at/gmail/dot/com>
> Version: GnuPG v2.0.22 (MingW32)

---   ---
Eduardo Morras <emorr...@yahoo.es>
fossil-users mailing list

Reply via email to