Re: [fossil-users] versioning system suggestions for a musician?
On Mon, Sep 29, 2014 at 5:59 PM, Andy Goth andrew.m.g...@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. 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. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] versioning system suggestions for a musician?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/2014 1:45 PM, Ron W wrote: Hello, Andy. Haha, actually I just forwarded the original post on behalf of Inverse Phase who is not subscribed. I forwarded your reply because you Cc:'ed me rather than him. Replies in this thread need to be Cc:'ed to: Inverse Phase inverseph...@gmail.com - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKbVzAAoJELtYwrrr47Y4HgkH+gJCX/tJOsPIxCC1xWRMyRTe sqdibNM+5vWOmmBNB6mwnjO6f7VuRG3qW4V1TOV2HU7TMKNmi7KI2c20AsSND97U VLbyhCwH8UpAfEpd7GIFctQoFPZrWlx5dkTkHS/WNaeVoVATONNPPCOYlfNfTOVF WDNMDIgqfMvD6IQUy4IeTiG0InWEIB+yA1N/PFCRBwgy1rUVlsuP9bO/OSpgfME+ Wm6lWkXuhL0qOXGOCCr0HupkJMCjoLpShQRVaqZjhzevZwJCEJYc8K6URvYKksat GRnHyrnZERO1FeKPOYx3yZvGIRMyGofO9IMQFK93vGpMUB/9Pk7ejqi35ALGKkE= =RAHC -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] versioning system suggestions for a musician?
-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
Re: [fossil-users] versioning system suggestions for a musician?
On Mon, Sep 29, 2014 at 3:50 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 9/29/2014 11:04 AM, Stephan Beal wrote: 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. Does Fossil hash only the file content or does it include meta data, such as the file name, in the hash, as well? ___ 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] versioning system suggestions for a musician?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/2014 4:28 PM, Ron W wrote: Does Fossil hash only the file content or does it include meta data, such as the file name, in the hash, as well? Only the file content. Confirm this by running sha1sum on a file, then running [fossil artifact] with the checksum as the argument. You should get the file's contents back again. Yup, Fossil is so amazing it knows how to reverse SHA-1. :^) - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKhbfAAoJELtYwrrr47Y4BvQH/1O/kO+ncw5vKpdi8dc6rCt/ cSQ/wDz2BKE1EOfxy+s1zIfozRaZx+/5Pwxc6RrUcjZry0kOf6bORya6RrBD8IVo bCFsrcQ0dQ+KPoAlwM96FoEoA9yMofN9jFbkdrrO6SfvHdXIuNh7Rm29ffttXr8n F3gbeOisWpUjXV2Ywev69FZly+gBvHJC6UEID9MTZ0r6wnfhrLSsoHGx0ktkGrUq 3roOyp810L4MzPkZaFTrRaS6kC8h/0WmSg2T+hJQi9eyPSnTTzTtnACWg6Mj7lF9 /kMfZMw4p2Yh4MYy5Mb6BLjM7paXn1BO21mwJeVeLCHeEuaJcxROR0JrCxP/IGk= =ejBc -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
