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 | -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
Re: [fossil-users] versioning system suggestions for a musician?
On Mon, Sep 29, 2014 at 3:50 PM, Andy Goth 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?
On Mon, Sep 29, 2014 at 3:39 PM, Andy Goth wrote: > > 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 Oops. Sorry I missed that. And thanks for forwarding my reply. ___ 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 > 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 | -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?
-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 - -- Andy Goth | -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?
Hello, Andy. For what it's worth, I am an amateur musician, so I have some appreciation of what you are trying to do. I also use Linux. (my "day job" is software development, so a good RCS is important to me) On Mon, Sep 29, 2014 at 11:59 AM, Andy Goth wrote: > > One thing that is very "un-RCS"-like that I'm trying to do is reorder > commits. For searching/reporting purposes, Fossil allows defining SQL queries. You could add your own tags to commits to label them with the dates you want, then SQL for searching and ordering. It won't change the order of the commits, just the listing order. Unfortunately, the time line view does not support custom SQL queries. (Though, once you get your backlog in Fossil (or other RCS), and get used to using a RCS, you are less likely to need re-ordering.) Otherwise, as best I know, the closest you could get with any RCS would be to place the commits into their own branches, including the "defined" date as part of the branch name. > To show that I'm paying attention, how about I use the "Why Fossil" list > as a guide... > > Bug tracking and Wiki: Don't care much. I would like to mark what I do > like or don't like about a revision, I do listen to tracks and notice > things I need to fix and that could be nice, but my music is, generally > speaking, not open to the public and won't be a collaborative effort. > Commit comments do allow wiki mark up, so can provide some formatting and can easily link to wiki items. Tickets don't have to be limited to bugs. They can be a useful way to manage "to do" or other items for follow up. > Web interface: useful to me for "at a glance" stuff, very handy. > > Autosync: not sure about how this relates to forking and merging for a > singular project, probably more useful for collaborations. That said, I > would love if something watched my filesystem and uploaded every new > save of a project and popped a dialog asking me what's new in the latest > save, including it as a commit comment or whatever. > You mentioned a laptop and a desktop, so you seem to have multiple PCs you use. Autosync will help you keep your project files up to date on all your PCs. > Self-contained: attractive but not necessary. I run linux and I'm not > afraid of compiling and installing something. But being able to move > everything around easily is helpful. Autosync will help with moving project files between PCs. > Being able to poke at revisions > from the filesystem rather than from the web interface is valuable just > in case the RCS is not functional for some reason. > The Fossil command line is always available as long as the file containing the actual repository is accessible. Each PC would have its own copy of that file, so the only things you won't have when the Fossil server isn't running are autosync and the web UI. > > Simple Networking: Useful, don't need to worry about dialup, tethering > off my phone is as fast as shitty DSL in a worst-case scenario. > This really means that geting Fossil one PC to talk to a Fossil server on another PC is relatively easy. > CGI-enabled: reading the description, I don't know that I care if things > are centralised or decentralised, I plan to use my desktop as a master > host for repositories, but having a slave backing up the repos somewhere > would be nice. > "CGI-enabled" just means you can put a "real" webserver (like Apache, Enjin or Lighttp) in front of Fossil. Fossil doesn't need this and can function as a web server. The Fossil website is running on Fossil. > I see the thing about "Events". would that be useful for, say, an "album > release"? is that what people use for releases of a specific version of > their software? > Events are just a type of wiki page where the page name is a date/time instead of a name. They could be useful for documenting a release, but I usually have a ticket for a release, so I just include links to release documents in the tickets (or in the commits) that correspond to releases. Another use for Events would be to keep an ongoing log of notes in chronological order. But I usually have tickets, so I just put such notes in the ticket comments. I don't think Fossil is any less suitable for your needs than any other RCS. I like Fossil for the "low hassle" factor. ___ 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 5:59 PM, Andy Goth 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
