SUBVERSION

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent

SUBVERSION
by somekool on Sunday 24/Oct/2004, @19:44

Wow ! I really enjoy reading those comments on the Digest.

thanks got there is peoples thinking about what consequences such a change would make.

here is what I think, why not fixing CVS instead of switching the world to a new system which input so much risk.

we could simply sit on the problem and add a 'cvs mv' functionnality.

I think a shell command to move the file is not enough, it breaks old history. like if you move some important files and then you want to retrieve KDE 3.1, you won't be able to get that file.

I think a proper move would be

shell 'cp old new'
cvs delete

so the old copy is available for older TAGs, and new project version continue to works with all file history.

would it be that hard to modify CVS and submit them back the patch ?
would not change much to the core system, and would fix this discussion definitely.

people would need to upgrade their client, once, in order to be able to use 'cvs mv' functionnality. that's it.

Related Links

·   Articles on Developer
·   Also by somekool
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: SUBVERSION
by Burrhus on Sunday 24/Oct/2004, @19:55

What do you do when someone moves it back? Or moves it to another file that previously existed?

[ Reply To This | View ]

Re: SUBVERSION
by somekool on Sunday 24/Oct/2004, @21:42

right, I guess we would need to handle that case to.

well, before we write, I guess CVS is able to know if there was a file before or not.

in case where a new file is written over an old delete one, cvs could kinda "reopen" the file, and commit a new version to it. (even if completely different).
so the old exist and the new one too. the only big question, is how to make the file unexistent between the too alive state.

and I agree there... moving back the file is quite more interresting challenge, cuz we want to prevent all history right.

If we are moving the exact same file, we could run a diff. see, if <oldfile> goes from 1.1 to 1.24 and <new file> is 1.1 to 1.98 and all version from <oldfile> exist in new file, well, we can just copy over the new one to the old emplacement, cvs delete the old emplacement of the <new file> and we are pretty much ok to go. except if there is branches, I suppose it gets really really more complicated. but at least we got a hint for a way to go now. there is people out there much better than me which would think about what I don't.

this is feasable.

about the last case where you move an existing cvs file over a old cvs file location... this one becomes really tricky. since both history can hardly be kept. but I suppose this could be forbidden, or cvs could ask what do you want to do, like different scenario is possible.

come on guys.

[ Reply To This | View ]

Re: SUBVERSION
by JohnFlux on Tuesday 26/Oct/2004, @11:45

Hey good idea. Lets fix all the cvs bugs, but keep all the commands similar so as to not confuse anyone, and keep it basically the same.

Then we'll change the name of it from cvs to something else so as not to confuse anyone. svn sounds like a good name to change it to. Yeah lets do that!

Oh wait.

[ Reply To This | View ]

Re: SUBVERSION
by Janne on Sunday 24/Oct/2004, @23:29

"here is what I think, why not fixing CVS instead of switching the world to a new system which input so much risk."

AFAIK, Subversion's intention is to "fix CVS". If you want to fix CVS, you can do so by moving to Subversion, which is the "fixed CVS" ;).

[ Reply To This | View ]

Re: SUBVERSION
by Mr. Fancypants on Monday 25/Oct/2004, @00:37

> here is what I think, why not fixing CVS instead of switching [...]

Don't you think people have been trying to fix it for ages? The whole reason for the Subversion project was that people were trying to fix CVS, but simply couldn't. It proved to be impossible to implement real atomic commits, real moves, etc. without changing the repository format. If you're going to change the repository format anyway, you might as well start with something completely new (or so the thinking goes).

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Default settings are easy to manage." -- Aaron Seigo
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.