-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/29/2014 11:04 AM, Stephan Beal wrote: > On Mon, Sep 29, 2014 at 5:59 PM, Inverse Phase > <inverseph...@gmail.com> wrote: > >> One thing that is very "un-RCS"-like that I'm trying to do is >> reorder commits. I say this because I have like 20 files that are >> all the same song. I need to just be like "these 20 files go to >> this song/project" and then decide after-the-fact which ones are >> oldest or newest. There's a very real possibility that I would >> discover an "even older" version of the track later on, so I need >> to be able to place something specifically before the first >> commit and so far I think most RCSes base everything off of >> whatever that is. I need to be able to go in either direction. > > That one criteria alone would seem to rule out _any_ SCM for this > purpose (include good old RCS). i'm not aware of any SCM which > allows one to arbitrarily reorder the history. git allows it, to > some degree, but i'd be surprised if it can handle the level of > "moving around" implied by the above description.
A month or two ago I brought up this same possibility on the list, and the idea came forth that heretofore unimplemented control artifacts could override the predecessor displayed on the timeline. This wouldn't change the P cards in existing manifests (impossible), nor would it change the delta compression "from" versions (meaningless). It would only override the P cards for timeline purposes, much the same way comments, dates, and tags can be overridden. >> There's also a possibility I will accidentally commit the same >> exact version of a file from a different system — say, my laptop >> — with or without a different name, and possibly after I've >> already committed a newer revision of the file, which is one of >> the reasons I want that feature to be particularly robust. > > In such a case Fossil would record both commits but store the > file's contents in a single artifact (because it recognizes them by > SHA1 hash, and the hash would be the same). i.e. it would not > duplicate the content, only the record of the change. The neat thing about this situation is that when you look at the artifact info page, it will show the artifact as being part of multiple commits, including those tagged with different branches. This way you can track down all the times when you had a given version. I'm also reasonably sure it'll also work for the case of multiple filenames mapping to the same contents. If you want to see if a given file's contents are already present in the repository, just run sha1sum on the file and go to the info page for that checksum. Feel free to type whatever URLs you want into the browser even if there aren't forms and links to generate them. - -- Andy Goth | <andrew.m.goth/at/gmail/dot/com> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKbf1AAoJELtYwrrr47Y4HHcH/j9aK4hwYmazw5gqbpfAZX+O 8CjydYoBEn0gbNCssOvK6+v2QmegyL7M2K7smeIxS2xCn6zNLBSVjIFy4bPR8eap Vsjcr4PCqwQimz91WWGVlZ537Bv4MmmTg06pESQU0DzAhNgYUP9ERgg+6cuBAScy qJHAHndjOAi50I3arjQL38SXgmoPqVX74Kxe8qms/mz5E3btIV3kQh2WSKhlX/vG E+tc3SZHIRaTiAm00/BQcuGR0CzMnjqAc1z5N/33ecVlGtap3IQ3rC21mibm3Tys WX8sE3L6Wx2loaxZHw0W3HEIft6+UizKJ80qQ7XPs2KRZuQNCp6aQMUzMffy5Uw= =esHC -----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
