--- Matthew Herrmann <[EMAIL PROTECTED]> wrote: > Hi Paul, Noel, > > I was thinking about a similar idea to yours. I also > thought of another way > to allow renames etc, although it would probably be > grossly inefficient > though elegant in its own way: > > Store all the directories, files, etc. in a single > mergeable text file > format. Then, on commits, the directories are put > back into this text file > which is commited. On update, the existing files are > merged into a text file > then a normal update is performed. Then, from that > file, the individual > files are broken out. > > Ads: > - Metadata can be stored, file location etc. > handling renames > - Revision numbers are unique and can become useful > (like give me a diff > versus the last checkin) > - Commits are atomic > - Branching etc. is trivial, don't have to worry > about "oh i lost that file" > etc. > - Diffs between two tags work better because the > revision numbers are > incremented every time a change is made in the > project > > Disads: > - slow (i'm guessing cvs is optimised to work on > lots of smallish files) > - concurrent dev is slowed by requiring a cvs update > on basically every > commit, not just when you have changed the same file > as someone else. > - it kind of undoes the point of cvs > > Just thought i'd throw that in -- the disadvantages > most likely render it > impractical, however.
I agree. To add one more "Disad", binary files will render this scheme useless. Or, from another POV, it would be impossible to use the above with binary files. Noel __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
