RE: [eclipse.org-committers] Installing SVN

["Ed Willink" <ed@xxxxxxxxxxxxx>]

> You win some and you loose some. SVN has atomic commits. It 
> might seem 
> like a trivial feature for those who rarely experience 
> network problems 
> but for us who do on a somewhat regular basis, it's very 
> valuable. SVN 
> can also revision directories as well as files. Very hard to do if 
> you're using a file system. SVN doesn't loose track of history just 
> because you move or rename a file. All of those features are 
> contributed 
> to the fact that SVN uses a database and hence, isn't subject 
> to all the 
> limitations you have in a file system. Revisioned data is 
> after all not 
> files. It is fragmented pieces of information. The CVS model is IMHO 
> severely limited.

A good summary of why SVN should be better. Unfortunately SVN or
at least its tooling just doesn't work.

An atomic commit requires that I can batch up numerous different
commit candidates with distinct commit comments. I can't; the tooling
requires a separate commit per comment.

I know of no benefit from revisioning directories, but suffer numerous
pains when directories have outgoing changes (e.g. svn:ignore) while
their contents have incoming changes. The default Subversive connector
doesn't support folder comparison to try to understand the problem.

I have yet to see SVN track a rename. A Windows Explorer move or copy
is treated as delete+create. An Eclipse refactor is similarly delete+create.

And if you want a bit of fun, try cleaning up the bin trees after JDT has
copied the .SVN folders! OK, maybe one day I'll learn to switch off
auto-build in a new workspace before I do check outs.

Until the tooling works, SVN causes much more pain than joy I'm afraid.
The CVS tooling is just too smooth to move on. 

	Regards

		Ed Willink