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
