SVN timing
Dirk Mueller
mueller at kde.org
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.
--
Dirk//\
More information about the kde-core-devel
mailing list