info-cvs
[Top][All Lists]
Advanced

[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
files.

Noel

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/



reply via email to

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