[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: renaming under CVS

From: Noel Yap
Subject: RE: renaming under CVS
Date: Mon, 11 Mar 2002 06:32:47 -0800 (PST)

--- Matthew Herrmann <address@hidden> 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


Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]