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. Regards, Matthew Herrmann -------------------------------------- Far Edge Technology Level 11, 80 Mount St North Sydney NSW 2060 Australia Ph: 02 9955 3640 Mob: 0404 852 537 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
