Steven Bosscher <[EMAIL PROTECTED]> wrote:

>> Thanks Danny for asking. I'm reading the various messages coming to the
>> list and, well, I'm *worried* the benefits will *not* outweigh the costs
>> for many of us.
>>
>> Sorry for the harsh and naive question: *which* are the benefits for
people
>> *not* managing many branches?
>
> Hmm, let's see.  The ones I care about most are:
>
> 1) Atomic commits, which make regression hunting a lot easier.
>    You can pinpoint exactly one patch, one revision, as the
>    thing to blame.  Right now the regression hunter can from
>    time to time do checkouts from a data+time when someone was
>    just checking in a patch.  With SVN, this is not a problem.
>
> 2) Ability to rename and move files.  Have you ever looked at
>    the messy structure of gcc (i.e. the compiler proper)?  And
>    don't you ever have the feeling that some libstdc++ file is
>    in the wrong place, but you don't want to move it because
>    it breaks the revision history?  SVN helps here.
>
> And less important but still nice:
> 3) Faster tagging, so you don't have to worry about not checking
>    out something when a gcc snapshot cron job is running

I'll add others:

4) Uniquely identification of a tree with a single number. "In my pristine
tree, revision 567890, I see this bug". That's unique.
5) Much much faster management of working copies: "svn diff" / "svn status"
do not require server connection. "what's up in my tree" and "what did I
change" can be answered in milliseconds.
6) Much easier reversion of patches for testing purposes, since you can
easily extract and revert an atomic changeset.
7) Much easier generation of proper diffs to send mail to the lists, since
you can "svn add" and "svn delete" without write access to the repository.
8) Fast switch of working copies from a branch to another, *maintaining* the
local changes. This is very handy.
9) Much easier backport of patches to release branches: "svn
merge -r123456", which also correctly remove/add/rename files as needed.
10) Getting rid forever of the problem with DOS newlines in source files.

I would also notice that most people don't RTFM. I spent many efforts in
writing the Wiki page, and the benefits of SVN are apparent if you spend
some time reading it and studying the thing a little. To make things better,
something *has* to change. You can't expect SVN to be *identical* to CVS,
but it's very very close.
-- 
Giovanni Bajo

Reply via email to