SVN timing

Dirk Mueller mueller at
Wed Mar 23 22:32:12 GMT 2005

On Wednesday 23 March 2005 23:08, Christoph Cullmann wrote:

> What does we get:
>   - O(1) branching (== svn copy)

Yes, we need way more branches in our repository. 

>   - binary diffing

I read binary diffs every day :)

>   - networkless revert/diffing

thats what you have  a ~/clean/ repository for with CVS and a cvs update 
wrapper script. 

>   - real move/copy without serverside hacks

- no way to remove failed imports, fix repository screwups server-side. no 
anoncvs servers for users anymore (we have >= 600 people using anoncvs 
servers every day). 

- and SVN does *not* support REAL moves. what it does is a copy with history 
preservation, exactly the same we do in CVS. A real move is still on their 
TODO list, and it will require a new SVN server backend. 

- no way to remove modules or other stuff from the repository. 

>   - more stuff :)

well, atomic commits and less commit log messages (if only e.g. translators 
wouldn't commit each file separately). too bad we already have atomic-commit 
log messages with CVS, so no difference here. 

Also, we loose website updating for a while until we fixed all the servers. we 
loose all server side scripts doing automatic stuff on our repository. no way 
to clean out old commits or branches. Probably 100 people not being able to 
remember their CVS password and asking sysadmins to setup a new one. 

snapshot generation and half a dozen other scripts I maintain will be broken 
until I find time to convert them. even then we'll probably spend several 
weeks fixing all the regressions. 

loosing "checking out by date" ability. no way to find a commit by date, no 
way to reliably diff  the repository by date. 

Ah, also we'll experience a factor 2-3 slowdown of all repository operations. 


More information about the kde-core-devel mailing list