Re: [fossil-users] Receiving old versions
On Sat, 30 Aug 2014 15:03:32 -0500 Andy Goth andrew.m.g...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/1/2014 3:20 AM, Eduardo Morras wrote: 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. No, as Richard pointed out, there is no way to change the predecessor of existing manifests. Predecessor artifact IDs are stored directly in the manifest, so they contribute to the manifest's artifact ID, which in turn is the predecessor artifact ID of subsequent manifests. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUBKN2AAoJELtYwrrr47Y4xMUIALeja1VV97mJV42eiugtfR9U ZFroPRgZ+Fvu06/UCrAeC+0vJUD49UwEO3k9leOHXXbf1ZZb9ZvLYpDHoevwGa1Z ALnCzq1cQF1+jRrK+UH+xxFEbub32VAphRICt4W3F+PJWiyyZRFHg6RXSocL1B+R s2l3MJaR5o7QscPck3jCUi6FpVUOq+lMA1HWJs74a+A5C/vScfzE48eem00HFn6F a2DkCFYS7gHZt4SOgPVcKo41r0xuaMthX0Im4K2Q5KUOL0Nfg8A81HVOXbDRiD5G Mi/aJNKH84yx/g4gGz+LzJaTOan70ffW2pxM8IIqfG+E/s791FGta0WtiDV5FZU= =5dIR -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
[fossil-users] Receiving old versions
-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? 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
Re: [fossil-users] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- 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? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAi4UAAoJELtYwrrr47Y4J8MIAMbIomO0T3d/lNiClwMi7Ph1 uoeWBPmmz1hd8cQlgT0uS/u6bhYQkOSqeDRM3kWPJCV9iDeRAdQ2wfJjT2/iv3ez OWQGDQcveIL36yBVzBAzGMmTrLKxtSxSZ5gjHzi6t7hn3bALz+6JySbDiHqUhNui 0QlvLz1+I0JyUepWw4OXzX6FzTUY4ldgZWz88N6DojX89zTdnwJo4sgFj8tV 1iL+xIwoQVDzoB+UMPc4uLGuMTSBDU5rzQS9ohvliniadoRPeI52BanLnm3zNP36 pp1BI3cKKynJH1DPP7ybTD0Y3XM6HqQUiO83JCsZSBAtn44zKJ86Qwpb/zzpIog= =g08t -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
Re: [fossil-users] Receiving old versions
On Sat, Aug 30, 2014 at 3:40 PM, Andy Goth andrew.m.g...@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 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
