Why SVN?

[Gary Wright]

Developer A is working on a major task. He has already changed a lot
of software locally. Now A gets aware that he needs B doing some
modifications in some other modules where B is the real expert.
Neither A nor B can propagate his own changes solely, because that
would break the build for all other developers. This is a normal
branch situation, but the branch situation has been recognized very
late. In addition A and B have to work some more time on the common
task, which means that they have to interchange and synchronize their
software releases several times without disturbing the others.

I'm just learning SVN, but can't this problem be handled as follows:

- Create a branch in the repository
- Developer A uses svn switch to associate their local files with the
new branch
- Developer A commits their changes to the branch
- Developer B checks out the branch

I'm not trying to make any point re: distributed vs centralized
repositories
I'm just trying to determine if I understand how this might be
handled in SVN.


Gary Wright

 

[Glen Pfeiffer]

I'm just learning SVN, but can't this problem be handled as
follows:

- Create a branch in the repository
- Developer A uses svn switch to associate their local files
with the new branch
- Developer A commits their changes to the branch
- Developer B checks out the branch

If I understand the presented scenario correctly then you are
absolutely correct.

 

[Robert Dober]

I can't resist replying to this troll. I call FUD on the "distributed
version control systems without much proven technology behind them"
claim until we get details. I'd really like to hear why you think you
have a winner just because something is different. It's obvious you
think you have a great reason to feel strongly about using Subversion.
I think it is only fair that you share why if you plan on telling
people such absolutes. So please, enlighten me.

Brian.

Austin a TROLL??? Well maybe he has adopted a troll like language but
I believe that you should see the context of all his contributions.

I defend him because I dislike him a lot and I find his Unix hatery
quite boring.
BUT he is a very valuable contributor.

So consider twice putting him into your kill file.

And yes of course Austin you have the right to holler at me, I was
quite harsh...

 

[Brian Mitchell]

Austin a TROLL??? Well maybe he has adopted a troll like language but
I believe that you should see the context of all his contributions.

I defend him because I dislike him a lot and I find his Unix hatery
quite boring.
BUT he is a very valuable contributor.

So consider twice putting him into your kill file.

And yes of course Austin you have the right to holler at me, I was
quite harsh...

I know very well who he is. I don't really care who he is if he makes
a large and absolute claim w/o backing it up. No special cases for
contributors either. I don't think the acts are mutually exclusive.
This is one of the most beautiful things about the Ruby community. The
fact that some people even question Matz sometimes about his thoughts
and proposals is a sign of good health. No blind worship to be found
here please.

Now given that, I wasn't about to kill-file him. I don't mind just
archiving or deleting email I don't like. Kill-filing seems to be a
bit far for most cases (Ilias might have pushed that line though ;-)
). He did an excellent job replying to my original concerns and made
his claim fair.

While I didn't really agree with what he would do in my cases, I found
it much more logical once he put his position into the picture. It
rather enriched the conversation in my opinion but w/o that, it really
put a dull spin on things leaving a void of an answer just sitting
there.

A lot of people have my respect and thanks. Austin is one of them. I
will still try to play a fair game here still. Holler at me and call
me a troll if I don't.

Thanks,
Brian.

 

[Robert Dober]

I know very well who he is. I don't really care who he is if he makes
a large and absolute claim w/o backing it up. No special cases for
contributors either. I don't think the acts are mutually exclusive.
This is one of the most beautiful things about the Ruby community. The
fact that some people even question Matz sometimes about his thoughts
and proposals is a sign of good health. No blind worship to be found
here please.

Now given that, I wasn't about to kill-file him. I don't mind just
archiving or deleting email I don't like. Kill-filing seems to be a
bit far for most cases (Ilias might have pushed that line though ;-)
). He did an excellent job replying to my original concerns and made
his claim fair.

While I didn't really agree with what he would do in my cases, I found
it much more logical once he put his position into the picture. It
rather enriched the conversation in my opinion but w/o that, it really
put a dull spin on things leaving a void of an answer just sitting
there.

A lot of people have my respect and thanks. Austin is one of them. I
will still try to play a fair game here still. Holler at me and call
me a troll if I don't.

Why would I do that? It is rather me who is wrong, I actually thought
that you are a newbie, what a memory I have, and I thought it might be
a good occasion to say what I think and warn someone not to lose vital
information.

So I just made a fool out of myself, great.

I can only apologize for the misjudgment of the situation...
I do that quite often though lately

Thanks,
Brian.

Robert

 

[Michal Suchanek]

See now this is interesting. Cause I feeling inclined toward Git for
these same reasons. In fact here's a diagram of me being torn:


I, Torn

O
SVN <-- --|-- --> Git
/ \
Solid Darcs Faster
Popular Stronger
Supported Better


Not that Darcs hasn't been good to me.

T.

I would agree with a picture like that

I mostly only check out projects, and recently I saw some that switched to git.

From the checkout/compile point of view git is pretty much the same as
cvs. But once I had to make a modification it became different. In the
end I found working with the modifications easier and cleaner.
However, I would be very disappointed if I found myself on Windows and
could not use git because of that.

The possibility of working offline is important for people who have
experience with crappy net coverage. I would count myself in, but I
understand that in some places such issues are nonexistent.

It looks like the distributed systems are new and more powerful which
means people have to get used to it. And many probably never will.
Also some features like crossplatform support have to be ironed out.
So I would guess the only reason to use them right now would be
experimenting or some features that are not easily obtained elsewhere.

Thanks

Michal

 

[Austin Ziegler]

Austin a TROLL??? Well maybe he has adopted a troll like language but
I believe that you should see the context of all his contributions.

I defend him because I dislike him a lot and I find his Unix hatery
quite boring.
BUT he is a very valuable contributor.

Hatery?

I'm not sure what you're reading, Robert, but in no way am I a Unix
hater. At work, I'm now running Ubuntu as my primary desktop (with
Windows as a VM) and have switched to OS X at home. I develop
professionally for Linux, AIX, Solaris, and HP-UX -- and Windows. What
I refuse to do is to accept Unix-only solutions for things, because
that's just chauvinism that has no place in Ruby, IMO.

-austin

 

[Robert Dober]

Hatery?

I'm not sure what you're reading, Robert, but in no way am I a Unix
hater. At work, I'm now running Ubuntu as my primary desktop (with
Windows as a VM) and have switched to OS X at home. I develop
professionally for Linux, AIX, Solaris, and HP-UX -- and Windows. What
I refuse to do is to accept Unix-only solutions for things, because
that's just chauvinism that has no place in Ruby, IMO.

-austin

Fisrt of all thx for replying in this cool way I appreciate.
Sorry Austin if I do not read your mails carefully enough, I will try
to change this.
But I was pushed by the rather err aggressive wording of yours to come
to that conclusion.
If that conclusion was jumped you did very well to tell me nicely as
you are very credible in this way.

I freely admit that there is an OS that I hate, maybe I should shout
that out loudly even if it is politically incorrect instead of
compensating by believing that others hate Linux/Unix.

In the end it is me who behaved trollish here, kind of some old untold
frustration about somebody hollering at my beloved Linux/GNU/Cygwin.

I really appreciate the way you were handling this...

Best regards
Robert

 

[Michal Suchanek]

Hatery?

I'm not sure what you're reading, Robert, but in no way am I a Unix
hater. At work, I'm now running Ubuntu as my primary desktop (with
Windows as a VM) and have switched to OS X at home. I develop
professionally for Linux, AIX, Solaris, and HP-UX -- and Windows. What
I refuse to do is to accept Unix-only solutions for things, because
that's just chauvinism that has no place in Ruby, IMO.

Yes, port to such alien environment like WIndows is the litmus test of
portability

As one should not accept solutions that "work for the 90% of users"
(on Windows only), one should not accept solutions that exclude about
half of the users (the Windows users).

Thanks

Michal

 

[Mike Schwab]

Professionally, I use subversion, though my team is looking to migrate
to something that does a better job at branch management and merging.

I have been thinking a lot about this too; the rule about not checking
in broken code seems to mitigate some of the agility that I'd like to
have. If I make progress and check in a branch, then I can delete what
I damn please in my further attempts to get it working. I will always
have those revisions to start from if it turns out my deleting was too
hasty. If I keep it local until it's passing tests, I don't have that
(but I can often approximate it by commenting lines out).

I plan to do a lot of branching for this reason. I have noticed,
though, that it is done somewhat sparingly in many of the repos I've
seen. Perhaps this is primarily related to project maturity, software
type, community circumstances. But I wonder if open source would be
that much more agile if the casual branching I described was more
common. It could be a bit like putting heads together to get it
working, begging feedback and brainstorm at more steps along the way,
rather than waiting until the code works to check in. Conversely, if
branching and merging is difficult enough that this luxury would rather
slow down the team, does the issue seem like one that can be addressed
in a future release, or is it an unavoidable consequence of svn's other
features? Mostly rhetorical here.

Last thing. svn has a new sync feature. Does this make it [more]
usable as a distributed repo?

-Mike
[-just got hired through workingwithrails.com; extremely humbled to join
the ranks of professional rubyists!]

 

[Adrian Howard]

I have been thinking a lot about this too; the rule about not checking
in broken code seems to mitigate some of the agility that I'd like to
have. If I make progress and check in a branch, then I can delete
what
I damn please in my further attempts to get it working. I will always
have those revisions to start from if it turns out my deleting was too
hasty. If I keep it local until it's passing tests, I don't have that
(but I can often approximate it by commenting lines out).

[snip]

You might want to consider using SVK as your client (if you're happy
using the command line). It's a distributed system built on top of
subversion - so you can mirror subversion repos locally and push/pull
changes between your local copy and the main one.

I've been using it for about a year as my primary way of talking to
subversion and have been very happy with it.

Cheers,

Adrian

 

[Greg Hurrell]

You might want to consider using SVK as your client (if you're happy
using the command line). It's a distributed system built on top of
subversion - so you can mirror subversion repos locally and push/pull
changes between your local copy and the main one.

I've been using it for about a year as my primary way of talking to
subversion and have been very happy with it.

Adrian, I'd love to hear more about your workflow. Could you give an
example of how you use this set-up for things like branching and
merging?

Cheers,
Greg

 

[Adrian Howard]

Adrian, I'd love to hear more about your workflow. Could you give an
example of how you use this set-up for things like branching and
merging?

Assuming $R is my "master" subversion repository I do something like
this

1) At the start of a project set up a mirror...

svk mirror $R/project/foo/trunk //foo/trunk

2) ... and a local branch

svk cp //foo/trunk //foo/local -m 'a local branch for local folk'

3) Check out a working copy into the foo directory

svk co //foo/local foo

4) Pull changes down from the central server

svk pull foo

I can then merrily work away in my local foo working copy committing
to my local branch on my local machine. When I want to push my
changes back to the central server I do

svk push --verbatim foo

(The --verbatim bit reproduces the commits you made to the local repo
on the remote one, rather than merging them into one big commit.
Makes it easier to track changes)

That's basically it.

Cheers,

Adrian

 

[Greg Hurrell]

That's basically it.

Many thanks for sharing.

Cheers,
Greg

 

[Randy Kramer]

I think you hit it in just one direction. The real value I find in
cherry picking is when I am providing a set of patches to an upstream
developer who may or may not want to merge certain things at any one
time. Most distributed systems handle this quite well though I think
darcs wins when it comes to the user effort needed. Other systems
often rely on complicated patch maintenance systems or force constant
"rebasing" patches with each revision (better than no support though).

The end result seems to be that you can avoid playing the baby sitter
between branches all the time. No more merge chores just to keep
things up to date. Of course, that isn't to say that avoiding merge
work always works either.

With all of this talk about SVN vs. anything not CVS, I would love to
see some ideas of how one could apply an svn interface to an existing
distributed tool. Some get close but maybe someone should make a
centralized "porcelain" for git? I don't see any reason you couldn't
implement a good portion of behaviors people seem to like.

I'm just catching up on some old email (so my comment may be far off the mark
(or out of date)), but you (anybody ;-) might want to look into svk (try
googling for it).

I haven't tried it, but it was recommended to me as sort of a front end that
would let me:
* use svn type commands
* maintain a local and remote repository (i.e., distributed)
* and the remote repository could be a variety of things, including CVS,
SVN, Darcs, and ...?

Randy Kramer

 

[Kevin Williams]

To comment on the original question, SVN has the following going for it:

* free
* cross-platform
* commercial support
* large installations
* vast community knowledge
* editor/ide/tool integration
* visual UI options
* good administrative tools/practices
* fair security/authentication tools
* written in a common and performant language
* stable

I've used VSS, ClearCase, Perforce(currently at work), CVS, SVN, Darcs,
SVK, and some others I can't remember. Perforce is very good, but
expensive. SVK - i do use it but I can't seem to get past my bias
against Perl. I couldn't even begin to look at Git because I use Windows
and Mac mostly. Darcs is performant, free, and cross-platform - all good
- but it doesn't compete against the list above, at least not yet. I'm
keeping my eye on it, though. I wouldn't use VSS, CVS, or ClearCase
again, given the choice.

I think this list is why SVN is such an easy choice. None of these are
perfect, so it comes down to your work style and project needs.
Distributed systems make more sense for start-ups with all remote devs
than in big brick-and-mortar enterprises with all on-site development.
Perforce would be hard to beat if it were free and had a distributed
option, but I don't see the free thing happening any time soon. Find
wide adoption and support of Darcs, or decentralization of Subversion,
and you may find a break-away leader. Until then you need to ask "which
one fits the way I/we work?".

Hope that helps.

 

[Ryan Davis]

Perforce is very good, but
expensive.

Not entirely true. To be clear: Perforce licenses are FREE for open
source projects.

 

[Austin Ziegler]

Perforce is very good, but expensive.

As Ryan said, this isn't completely true for open source projects
(although it seems a little harder for a non-GPLed project; I haven't
tried to set one up, yet). However, even for corporations, Perforce
isn't *that* expensive compared to some of its competition and how
much it provides, and the level of support is just amazing.

It's not going to be something that start-ups use first, though. If I
were to use Perforce myself, though, I'd set up a public read-only SVN
repository for others to access.

-austin

 

[Michal Suchanek]

To comment on the original question, SVN has the following going for it:

* free
* cross-platform
* commercial support
* large installations
* vast community knowledge
* editor/ide/tool integration
* visual UI options
* good administrative tools/practices
* fair security/authentication tools
* written in a common and performant language
* stable

I've used VSS, ClearCase, Perforce(currently at work), CVS, SVN, Darcs,
SVK, and some others I can't remember. Perforce is very good, but
expensive. SVK - i do use it but I can't seem to get past my bias
against Perl. I couldn't even begin to look at Git because I use Windows
and Mac mostly. Darcs is performant, free, and cross-platform - all good
- but it doesn't compete against the list above, at least not yet. I'm
keeping my eye on it, though. I wouldn't use VSS, CVS, or ClearCase
again, given the choice.

I think this list is why SVN is such an easy choice. None of these are
perfect, so it comes down to your work style and project needs.
Distributed systems make more sense for start-ups with all remote devs
than in big brick-and-mortar enterprises with all on-site development.
Perforce would be hard to beat if it were free and had a distributed
option, but I don't see the free thing happening any time soon. Find
wide adoption and support of Darcs, or decentralization of Subversion,
and you may find a break-away leader. Until then you need to ask "which
one fits the way I/we work?".

Hope that helps.

You did not mention mercurial which is easier to start with than
darcs. It uses python which is more widespread than the thing darcs
uses.
Unlike git I haven't seen a large project using mercurial (yet).
However, I guess pretty much all the advantages you named above would
apply to mercurial as well.

There is a link to SCM comparison site earlier in the thread. From
that it looks like the centralized SCMs are more space efficient in
some cases (ie working on part of the repository) at the cost of being
less flexible (only one central repository to which you need access
all the time, harder branching).

To me the move the use of distributed SCM brings complete new way of
thinking about code management that things like SVK do not. All the
repositories are the same, one may be "central" only because more
people use it than any other.

Thanks

Michal

 

[Bruno Michel]

You did not mention mercurial which is easier to start with than
darcs. It uses python which is more widespread than the thing darcs
uses.
Unlike git I haven't seen a large project using mercurial (yet).

Mercurial was choosed by OpenSolaris, but I don't know if it's already
used or not.

Source : http://www.opensolaris.org/os/community/tools/scm/