Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse.org-committers] Installing SVN

> 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




Back to the top