Re: CVS should die - Mailing list pgsql-hackers
From | kaz@ashi.footprints.net (Kaz Kylheku) |
---|---|
Subject | Re: CVS should die |
Date | |
Msg-id | cf333042.0411142341.68197cd4@posting.google.com Whole thread Raw |
In response to | CVS should die (was: Possible make_oidjoins_check ...) (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
List | pgsql-hackers |
twp@castle.fastmail.fm (Travis P) wrote in message news:<F54111AA-35EB-11D9-B14F-003065F9DAF8@castle.fastmail.fm>... > > "Misinforming the user on rename with local changes" > > dev@subversion.tigris.org > > news://news.gmane.org:119/419379F3.5070302@ftml.net > > Might be easier to read with a browser here: > http://svn.haxx.se/dev/archive-2004-11/index.shtml > > Yes, looks like it could be a potential problem/inconvenience if a file > is both moved and altered simultaneously. You guys should check out the software that I developed called Meta-CVS. It creates a version control system that has directory structure versioning, over top of the file versioning semantics provided by CVS. Meta-CVS does not have problems with these corner cases, by design. > I see the risk of problems as similar to those that if two people edit > the same section of the same file at the same time, complicated > conflicts could emerge. In Meta-CVS, conflicts in the directory structure are exactly like these conflicts, because the directory structure is marked up as a straightforward text document. When conflicts occur, you can read that document and it's obvious that one user wanted to rename foo.c to src/foo.c, whereas another one wanted to rename it to foobar.c. Meta-CVS completely separates the directory structure from the files, in the classic way: just like Unix file systems, and network file systems like NFS and others. A file is known by an 128 bit identifier encoded as text in hexadecimal. So for example, even picking up a deletion to a locally modified file is safe. Suppose you have been editing a document foo.txt, do a ``mcvs up'' and it's deleted. Your changes are still safe and can be committed. All that happened was that your foo.txt was unlinked from the directory structure. The real object, still exists, and has all your changes. It can be committed to CVS. Independently of that action, you can re-introduce your object into the directory structure: just change the markup document (a file called MAP in the MCVS directory at the root of your project) and then run ``mcvs up''. Meta-CVS will notice the change, and link the file into the appropriate place, as requested by the new markup. You can commit that markup change, and the file will reappear in people's sandboxes when they pick it up. > It is too bad the Subversion design didn't anticipate this such that > it's not a problem at all, but in many environments, it may not be much > of an issue. Fortunately, I anticipated the problem before I laid down the first line of code.
pgsql-hackers by date: