Forum: Ruby Why SVN?

Should I be using SVN rather than Darcs or Git?

Subversion has apparently become the version control system of choice
for Ruby developers --especially now that Ruby itself uses it. I
suspect that might have a lot to do with Rails and Rubyforge. Ruby
only switched over to SVN well after Rails had been using it. And
Rubyforge currently only supports SVN and CVS, which I find a bit
surprising since, from what I understand, supporting Darcs is just a
matter of having Darcs installed. And I can't imagine Git is much
different.

So I'm wondering, what's so special about SVN as opposed to the other
choices? Is it because SVN is more like CVS than the other choices?
The fact that SVN isn't distributed I would think would work against
it (though I hear SVK is supposed to deal with that). Darcs is written
in Haskell, and from the word on the street a lot of Ruby folk seem to
like Haskell. Also, Git was written by Linus Torvalds, which is about
as good as credentials can get.

Thanks,
T.

Why not SVN?

On 3/12/07, Trans <transfire@gmail.com> wrote:
> different.
> T.
>
>
>


--
"Hey brother christian with your high and mighty errand, Your actions 
speak
so loud, I can't hear a word you're saying."

-Greg Graffin (Bad Religion)

On 3/12/07, Glen Holcomb <damnbigman@gmail.com> wrote:
>
> Why not SVN?


This is going a bit OT for ruby-talk, but I'll bite.

I work from several different machines, in several different locations,
including from a laptop that is often disconnected from the internet. 
It's
extremely useful for me to be able to record changes, branch, work, in 
my
normal manner, without worrying about the fact that when I DO get a
connection all my changes will show up as one big lump.  So I use Darcs 
over
SSH.  It gives me a full, functional repository with "commits" as I need
them, without being connected.  Then when I get back to civilization I 
can
push all my changes back to my main repo and be good to go, SVN can't 
give
me that kind of work flow, so I've moved away from it.  (I'm aware of 
SVK,
but never could get it working well on linux/mac/and windows)

At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better.  Use the 
tool
that fits the job, and move on.

On 3/12/07, Trans <transfire@gmail.com> wrote:
> Should I be using SVN rather than Darcs or Git?
>
> Subversion has apparently become the version control system of choice
> for Ruby developers --especially now that Ruby itself uses it. I
> suspect that might have a lot to do with Rails and Rubyforge. Ruby
> only switched over to SVN well after Rails had been using it.

SVN is very much like CVS. It does have better handling of the
hierarchical structure of a project in that it versions the directory
hierarchy.  This makes it nicer for things like Rails which make a
fair use of directory hierarchies.

> And
> Rubyforge currently only supports SVN and CVS, which I find a bit
> surprising since, from what I understand, supporting Darcs is just a
> matter of having Darcs installed. And I can't imagine Git is much
> different.

I think it's a matter of the repository itself, they'd need to have
more parallel copies of the code in different repository formats.


>
> So I'm wondering, what's so special about SVN as opposed to the other
> choices? Is it because SVN is more like CVS than the other choices?
> The fact that SVN isn't distributed I would think would work against
> it (though I hear SVK is supposed to deal with that). Darcs is written
> in Haskell, and from the word on the street a lot of Ruby folk seem to
> like Haskell. Also, Git was written by Linus Torvalds, which is about
> as good as credentials can get.

A good bit of it is the relationship between CVS and SVN, if you are
used to CVS then SVN is a fairly easy transition.  Those two are
probably the most popular version systems around, so it's also a
matter of market share.

Git was written as a recovery from having the BitKeeper license yanked
out from under the linux project. FWIW.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Sorry I spaced and hit send before I actually typed more than my 
"subject".
I was going to suggest reasons similar to those put forth by Rick.

On 3/12/07, Tanner Burson <tanner.burson@gmail.com> wrote:
> internet.  It's
> At work, where I work from a single workstation, always connected to the
> > > only switched over to SVN well after Rails had been using it. And
> > > like Haskell. Also, Git was written by Linus Torvalds, which is about
> > "Hey brother christian with your high and mighty errand, Your actions
> tanner.burson@gmail.com
> http://www.tannerburson.com
>



--
"Hey brother christian with your high and mighty errand, Your actions 
speak
so loud, I can't hear a word you're saying."

-Greg Graffin (Bad Religion)

To quote from the SVN webpage:
Subversion is meant to be a better CVS, so it has most of CVS's
features. Generally, Subversion's interface to a particular feature is
similar to CVS's, except where there's a compelling reason to do
otherwise.

Without delving into specifics, SVN makes it a lot easier to do things
than CVS does, especially administrative tasks and branching etc.

It's powerful enough to draw hardcore CVS users to it, and power/easy
enough to draw hardcore VSS* users to it.

--Kyle


* Sometimes those hardcore visual source safe users are companies.
Whole big fat companies who makes oodles of money and don't bat an eye
at 3k/machine licensing fees.

The system that is used is a good one.

I have use Visual Source Safe, CVS and for last tree and more years
exclusively subversion.
There is no bad system but I wouldn't go back to previous ones.

I use subversion on my work and form all my home pet projects.

It is very reachable thought out various protocols, easy command line
syntax, has GUI Tools, configurable from administrator's point of
view, mature system, has lot of knowledge.

This can be taken as personal opinion colored by some personal
affinity. To take more objective approach investigates what big source
repositories sites using like Google or other Forge sites.

If you have time perhaps you can try all of them and find the one that
suit your needs.

Tanner Burson wrote:
> At work, where I work from a single workstation, always connected to the
> network, I use SVN, because it fits the environment better.  Use the tool
> that fits the job, and move on.

I agree - and to stress the topic further, there is this site which does
a comparision of version control systems based on features:

http://better-scm.berlios.de/comparison/comparison.html

I'm using SVN at home and ClearCase at work - in regard to what I know
of both of them the comparison looks sane.

I did choose SVN because I've heard about it. And it does work for me,
so I didn't switch to something else.

Well, and there is

http://en.wikipedia.org/wiki/Comparison_of_revisio...

I cannot answer the original posters question, so this is completely
off-topic.

Stefan

> There is no bad system but I wouldn't go back to previous ones.
Having used Visual Source Safe extensively I have to take exception to
that statement ;)

Trans schrieb:
> Should I be using SVN rather than Darcs or Git?
I use git for the reason of *very simple* branching and *fast* branch
switching. If I want to try something out, I create a new branch and
check it out. Then programming and testing a bit make commits of some
steps and if I don't like it I can throw the complete branch away
without changing the main development stream. If it is nice I merge it
and delete the no longer needed branch. Therefore I like git. :)

In subversion I have never create a branch: It was to expensive for me.

m2c
Jan

On Mar 12, 3:46 pm, "Tanner Burson" <tanner.bur...@gmail.com> wrote:
> On 3/12/07, Glen Holcomb <damnbig...@gmail.com> wrote:
>
>
>
> > Why not SVN?
>
> This is going a bit OT for ruby-talk, but I'll bite.

To be clear I'm asking why _rubyists_ in particluar choose one over
the other --not so off topic.

>
> At work, where I work from a single workstation, always connected to the
> network, I use SVN, because it fits the environment better.  Use the tool
> that fits the job, and move on.

So you actually use both. I hate the lack of DRY in that, but it looks
like I may have to go down that road too.

Thanks,
T.

While distributed version control systems offer some benefits, they're
still not really mainstream. Most developers are accustomed to the way
things are done in central repositories, and working offline is, with
the exception of maybe a short stint on a plane or train, not that
common nowadays. The benefits of darcs, etc. don't really justify the
effort that would need to be put into migrating the existent proven
infrastructure and potentially alienating some people who are put of
by the slightly esoteric nature of the alternatives. A clear case of
"if it ain't broke, don't fix it". That shouldn't keep you from
hosting your code in darcs though if you prefer.

   -tim

On 3/12/07, Trans <transfire@gmail.com> wrote:
>
> > push all my changes back to my main repo and be good to go, SVN can't give
> > me that kind of work flow, so I've moved away from it.  (I'm aware of SVK,
> > but never could get it working well on linux/mac/and windows)
> >
> > At work, where I work from a single workstation, always connected to the
> > network, I use SVN, because it fits the environment better.  Use the tool
> > that fits the job, and move on.
>
> So you actually use both. I hate the lack of DRY in that, but it looks
> like I may have to go down that road too.
Yes indeed, what is happening in the Ruby community is happening all
over the place.
SVN will simply replace CVS slowely but surely.
>
> Thanks,
> T.
>
>
>
Cheers
Robert

On Mar 12, 5:55 pm, Jan Friedrich <frd...@gmail.com> wrote:
> Trans schrieb:> Should I be using SVN rather than Darcs or Git?
>
> I use git for the reason of *very simple* branching and *fast* branch
> switching. If I want to try something out, I create a new branch and
> check it out. Then programming and testing a bit make commits of some
> steps and if I don't like it I can throw the complete branch away
> without changing the main development stream. If it is nice I merge it
> and delete the no longer needed branch. Therefore I like git. :)
>
> In subversion I have never create a branch: It was to expensive for me.

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.

Trans wrote:
> Should I be using SVN rather than Darcs or Git?
> 
No one else has mentioned it, and I'm sure it's not relevant for you,
but TortoiseSVN is enough of a reason in itself for me to choose SVN for
any project where I might have to do anything on Windows.  It's just
that good.

Other than that, I'm a big darcs fan too.

On 3/12/07, Tanner Burson <tanner.burson@gmail.com> wrote:

> me that kind of work flow, so I've moved away from it.  (I'm aware of SVK,
> but never could get it working well on linux/mac/and windows)
>
> At work, where I work from a single workstation, always connected to the
> network, I use SVN, because it fits the environment better.  Use the tool
> that fits the job, and move on.

Is this the only real compelling reason to switch to Darcs or similiar
alternatives?   For me I'm never off the net long enough for the
centralized repository in svn to become a problem.  Even when I'm
working from a laptop most of the day, I'll have free wifi available
somewhere to sync up.

- Rob

On 12-Mar-07, at 7:07 PM, Rob Sanheim wrote:

>> normal manner, without worrying about the fact that when I DO get a
>> but never could get it working well on linux/mac/and windows)
> working from a laptop most of the day, I'll have free wifi available
> somewhere to sync up.

The ability to cherry pick patches is also a real benefit.

--jer

Rob Sanheim wrote the following on 13.03.2007 00:07 :
>> connection all my changes will show up as one big lump.  So I use
>> At work, where I work from a single workstation, always connected to the
>> network, I use SVN, because it fits the environment better.  Use the
>> tool
>> that fits the job, and move on.
>
> Is this the only real compelling reason to switch to Darcs or similiar
> alternatives?   For me I'm never off the net long enough for the
> centralized repository in svn to become a problem.  Even when I'm
> working from a laptop most of the day, I'll have free wifi available
> somewhere to sync up.
>

I'm currently looking at decentralized version control systems for my
own needs. So it's my early ideas on the subject, feel free to correct
them...

Where it can help is when a developper has a bright idea and want to
implement it without impacting others. She creates a branch on her local
repository to try out her idea and work with it (and can do for a
longtime, merging patches from the branch she follows usually along the
way). If you often have ideas being tried out, it can be a benefit
because these branches would all be cluttering your common repository
with a centralized system (this is why you can have lots of Linux kernel
trees with git, each with its own purpose, the most popular by far being
Linus Torvalds' one).

This probably is a real benefit when you have lots of really good devs
all motivated to try out their ideas. This allows large group of
developpers to scale.

Lionel.

On Mar 12, 2007, at 6:13 PM, Jeremy Tregunna wrote:

>>> extremely useful for me to be able to record changes, branch,  
>>> me that kind of work flow, so I've moved away from it.  (I'm  
>> similiar
>> alternatives?   For me I'm never off the net long enough for the
>> centralized repository in svn to become a problem.  Even when I'm
>> working from a laptop most of the day, I'll have free wifi available
>> somewhere to sync up.
>
> The ability to cherry pick patches is also a real benefit.

Is it, really?  I'm not trying to be combative, I'm just wondering
how often that comes up.

It sounds darn cool to the geek in me, but I find myself wondering if
it happens a lot.  I guess I can envision a few specialized scenarios
where it could be handy, but I really don't feel I would use it much
for mainstream software.

For example, I really doubt there are many patches to Ruby I want to
skip out on.

James Edward Gray II

On Tue, Mar 13, 2007 at 04:25:50AM +0900, Trans wrote:

> Should I be using SVN rather than Darcs or Git?

Only if all your co-developers are.  But otherwise, probably not.

> So I'm wondering, what's so special about SVN as opposed to the other
> choices? Is it because SVN is more like CVS than the other choices?

Pretty much, it's also been around longer and thus is "more mature."

Subversion is reasonably familiar to those who are used to the CVS 
paradigm
of revision control.  Although just because people are used to it, and 
it's
popular, doesn't make it necessarilly good.  Frankly, I'm not much of a 
fan
of Subversion, although I much prefer it to CVS.

> Also, Git was written by Linus Torvalds, which is about as good as
> credentials can get.

Yes, however Git was written to achieve nothing more than managing the
Linux kernel.  The fact that it's applicable to other problem domains is 
a
coincidence, not a design feature.  If you're managing a project that 
much
resembles the Linux kernel, Git might be the right choice for you.  If 
not,
there might be an impedance mismatch.

Recently I've become a fan of Mercurial.  It has a few issues (besides
being written in Python =P), but otherwise I find it to be a better 
match
for my needs than Subversion.  I also considered Git, but I found it 
much
less approachable, although 1.5.0 is supposed to be easier to use.

My biggest gripe with Subversion is that branch merges are braindead 
(have
to specify revision boundaries), which makes branching much less useful
than it could be.  Two minor gripes are that the BDB backend was a 
mistake
only recently seems to have gone away, and that operations tend to be
painfully slow.

In general, I'm a fan of the distributed model of development, be it 
with
Mercurial, Git, Darcs, etc.  Branching is a great concept that isn't 
used
effectively in CVS or Subversion becuase of branch/merge limitations.

I like being able to checkout a project (often one I don't have
permissions to the central repository other than read), make a bunch of
local changes _and_ local commits that don't affect other users, then 
once
tested perform a branch push (possibly with a pull/merge).

I find that with Subversion folks are much less willing to make
intermediate commits since they tend to affect all users unless a 
separate
branch is used, and branches are difficult with Subversion.

The one scenario where I find Subversion really useful is when I
specifically don't want to maintain a local copy of an entire 
repository,
especially a large one like the Linux kernel.  With Subversion, I only 
need
a local copy of the checked out revision.  That's the one thing where I
wish there was better handling in distributed revision control
systems--although folks may claim that such handling would break the
paradigm.

On 12-Mar-07, at 8:05 PM, James Edward Gray II wrote:

> On Mar 12, 2007, at 6:13 PM, Jeremy Tregunna wrote:
>> The ability to cherry pick patches is also a real benefit.
>
> Is it, really?  I'm not trying to be combative, I'm just wondering  
> how often that comes up.

In certain cases it is, yes.

> It sounds darn cool to the geek in me, but I find myself wondering  
> if it happens a lot.  I guess I can envision a few specialized  
> scenarios where it could be handy, but I really don't feel I would  
> use it much for mainstream software.
>
> For example, I really doubt there are many patches to Ruby I want  
> to skip out on.

There may be patches I'd want to skip out on in other projects --
platforms I don't need support for, objects I won't use, you can
continue this line of thought. Not having the ability to just discard
those w/o affecting the repo's consistency, is nice. Sure it'd only
be used in corner cases, but when you stumble across such a corner
case, you'll wish you had that ability (or maybe you won't, who am I
to say).

--jer

On 3/12/07, Jeremy Tregunna <jtregunna@blurgle.ca> wrote:
> to say).
>

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.

Brian.

On Tue, Mar 13, 2007 at 09:21:36AM +0900, Mike Kasick wrote:
> The one scenario where I find Subversion really useful is when I
> specifically don't want to maintain a local copy of an entire repository,
> especially a large one like the Linux kernel.  With Subversion, I only need
> a local copy of the checked out revision.  That's the one thing where I
> wish there was better handling in distributed revision control
> systems--although folks may claim that such handling would break the
> paradigm.

Bazaar (also written in Python :-)) has had lightweight checkouts for a 
while:

http://bazaar-vcs.org/SharedRepositoryTutorial?hig...

They should also work for Subversion repositories.

Found this on Wikipedia.

"Many projects support both POSIX and Windows. Such projects typically
avoid using an SCM system that poorly supports Windows, even if most
developers use POSIX-based systems. Examples of projects that have
publicly ruled out any use of git, due to git's poor support of
Windows, include Mozilla [3] and Ruby [4]."


T.

> 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.

Porcelain? :) I was expecting to find a SVN UI with the google I just 
did.

> > The ability to cherry pick patches is also a real benefit.
> 
> Is it, really?  I'm not trying to be combative, I'm just wondering  
> how often that comes up.

I like the ability to develop a patchset as an object -- 'here, does
this set work?' -- and discuss. I like the orientation of discussing
changes rather than states.

I cherry-pick a lot -- it also lets me take my production copy -- which
has a couple site-specific changes to version-controlled files still --
and make a hotfix and push back to the repo from that without getting my
changes mixed in.

It suits my workflow.

The other thing to note is that you can use two SCMs at once. I quite
often push to a darcs repo that is also a SVN checkout. Once I get the
patchset to a state I like, I can commit a huge chunk all at once, and
use the darcs changelog to make a good commit entry.

I'm trying git with one project. So far, so good. It's also a really
good tool. And mightily fast.

Aria

On 3/13/07, benjohn@fysh.org <benjohn@fysh.org> wrote:
> > 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.
>
> Porcelain? :) I was expecting to find a SVN UI with the google I just did.

 From http://git.or.cz/

"Besides providing a version control system, the Git project provides
a generic low-level toolkit for tree history storage and directory
content management. Traditionally, the toolkit is called the plumbing.
Several other projects (so-called porcelains) offer compatible version
control interfaces - see the related tools list."

I guess that is the mentality you get from a linux kernel hacker. It's
all plumbing or it must be porcelain. :-)

Brian.

On 3/13/07, Aredridel <aredridel@nbtsc.org> wrote:
>
> The other thing to note is that you can use two SCMs at once. I quite
> often push to a darcs repo that is also a SVN checkout. Once I get the
> patchset to a state I like, I can commit a huge chunk all at once, and
> use the darcs changelog to make a good commit entry.

I'd love to hear about this in more detail (off list if you prefer),
in terms of best practices, any drawbacks you've discovered, etc..
We're in the process of moving from Mercurial to SVN at work, and if
possible I'd like to continue using Mercurial for developing
experimental features, and then check them into the main SVN
repository when they're completed.

martin

Hi,

In message "Re: Why SVN?"
    on Tue, 13 Mar 2007 04:25:50 +0900, "Trans" <transfire@gmail.com> 
writes:

|Should I be using SVN rather than Darcs or Git?

For your information, I use stgit for managing my local Ruby
repository.  I wanted to manage my experimental patches in stack
based.

              matz.

I like the ability to develop a patchset as an object -- 'here, does
this set work?' -- and discuss. I like the orientation of discussing
changes rather than states.

I cherry-pick a lot -- it also lets me take my production copy -- which
has a couple site-specific changes to version-controlled files still --
and make a hotfix and push back to the repo from that without getting my
changes mixed in.


[http://www.thtmobile.com]Mobile Solution
[http://www.thtmobile.com/partners.htm] Mobile Solutions

On 3/13/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
...
> For your information, I use stgit for managing my local Ruby
> repository.  I

Oh oh, Matz, you're going to get the pythonistas all excited <G>

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Mar 13, 8:09 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: Why SVN?"
>     on Tue, 13 Mar 2007 04:25:50 +0900, "Trans" <transf...@gmail.com> writes:
>
> |Should I be using SVN rather than Darcs or Git?
>
> For your information, I use stgit for managing my local Ruby
> repository.  I wanted to manage my experimental patches in stack
> based.

Cool. So how do you sync back up with the SVN repo? I tried using SVN
and Darcs on the same project and ran into problems. Maybe it's not a
problem with Git? Or do you have to do something special?

T.

Hi,

In message "Re: Why SVN?"
    on Wed, 14 Mar 2007 22:16:13 +0900, "Trans" <transfire@gmail.com> 
writes:

|Cool. So how do you sync back up with the SVN repo? I tried using SVN
|and Darcs on the same project and ran into problems. Maybe it's not a
|problem with Git? Or do you have to do something special?

I used tailor to import repository from svn to git.  After that, I
have a directory that have both .svn and .git sub-directories.  Maybe
git-svn would do better job.

              matz.

Hi,

In message "Re: Why SVN?"
    on Wed, 14 Mar 2007 19:07:15 +0900, "Rick DeNatale" 
<rick.denatale@gmail.com> writes:

|> For your information, I use stgit for managing my local Ruby
|> repository.  I
|
|Oh oh, Matz, you're going to get the pythonistas all excited <G>

I don't want to have prejudice against tools by the language they are
written, until I have to hack them.  I abandoned tailor (and svk) for
that exact reason.

              matz.

On 3/12/07, Trans <transfire@gmail.com> wrote:
> Should I be using SVN rather than Darcs or Git?

Yes.

Darcs and Git are distributed version control systems without much
proven technology behind them, and are painfully Unix-oriented.

> So I'm wondering, what's so special about SVN as opposed to the other
> choices? Is it because SVN is more like CVS than the other choices?
> The fact that SVN isn't distributed I would think would work against
> it (though I hear SVK is supposed to deal with that). Darcs is written
> in Haskell, and from the word on the street a lot of Ruby folk seem to
> like Haskell. Also, Git was written by Linus Torvalds, which is about
> as good as credentials can get.

Quality in kernel management doesn't mean his version control system
is any good. I'm not saying it's bad -- at all -- but the credentials
don't transfer there.

Distributed systems fit very few development models.

-austin

On 3/12/07, James Edward Gray II <james@grayproductions.net> wrote:
> Is it, really?  I'm not trying to be combative, I'm just wondering
> how often that comes up.
>
> It sounds darn cool to the geek in me, but I find myself wondering if
> it happens a lot.  I guess I can envision a few specialized scenarios
> where it could be handy, but I really don't feel I would use it much
> for mainstream software.
>
> For example, I really doubt there are many patches to Ruby I want to
> skip out on.

Spot on, James. Most of the time, patches can't actually be simply
cherry-picked in any environment.

It's easier with advanced version control systems like Perforce, but I
find I don't generally cherry-pick those anyway.

-austin

On 3/14/07, Austin Ziegler <halostatue@gmail.com> wrote:
> > The fact that SVN isn't distributed I would think would work against
>
> -austin

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.

On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
> 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.

Careful who you call troll. You'll find your assumption comes back to 
bite you.

Technology is proven by (1) wide use and (2) long experience. CVS and
Subversion at this point are proven technologies that are widely
adopted. That doesn't necessarily make them best of class, but it
means that people know what to expect from them. Some of that will
include bugs, but the core technology is proven. There are billions of
lines of code in CVS and Subversion systems being protected and
managed right now.

Subversion has meaningfully improved upon CVS and has improved the
state of the art for open source centralized source management. I
wouldn't dare call it best of class, but I would use it for any open
source project because it (1) has a lower barrier of entry across
platforms and (2) works in ways that people expect it to. I'm less
convinced that I'd use it for professional software development after
my experience with Perforce at my current job. Perforce is an
absolutely amazing piece of software that gives many of the supposed
benefits of distributed development platforms (lightweight branches,
patch cherry picking), and with p4proxy, you get better distributed
development (although *not* apparently disconnected distributed
development).

There's so many different distributed systems right now that work
differently from each other and have forked because of differences in
opinion on how the programs should work that it's nearly impossible to
choose one reliably. Many of them suffer from an extreme anti-Windows
bias and very few of them (if any!) have GUI support for visualizing
changes over time. I personally find disconnected distributed version
control systems to be very fragile in that entire branches can go away
because a middle version is purposefully or accidentally deleted.
People say that distributed systems have cheap branching, but I find
that very hard to believe, since (at least in the ones that I've
tried, and I have a hard time imagining how others would differ) the
branches are physical copies in a different location. That's cheap for
the making, yes, but your total storage cost goes up (since none of
the advantages of having a single repository can be found) and it then
becomes possible to *lose* branches from your repository (cf fragility
above).

There's a lot of things to like about the *ideas* of DDSCM, but in the
real world, I find that I'm rarely disconnected from the 'net long
enough to care about the fact that I'm using a centralised management
system.

So no, not a troll. Well informed using shorthands that should have
been pretty easy to determine if you weren't blinkered by the
proponents of DDSCM in the first place.

-austin

On 3/14/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
> > 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.
>
> Careful who you call troll. You'll find your assumption comes back to bite you.

I knew I could count on a good reply. I know you are a good debater. I
need not bring up the topic of benchmarking with you for example. ;-)

> Technology is proven by (1) wide use and (2) long experience. CVS and
> Subversion at this point are proven technologies that are widely
> adopted. That doesn't necessarily make them best of class, but it
> means that people know what to expect from them. Some of that will
> include bugs, but the core technology is proven. There are billions of
> lines of code in CVS and Subversion systems being protected and
> managed right now.

Yes. Though there a millions of lines of code written in languages a
lot here would consider primitive. There are also millions of more
lines of code being written with no version control as well (I would
guess, though there is no denying that this number is larger than it
should be). I think I will agree that the wide spread use is
important, but I don't think adoption is the only metric to look at.

> development (although *not* apparently disconnected distributed
> development).

No argument here. There are a lot of projects that thrive off of easy
entry. I think Ruby on Rails is an excellent example that many in this
community have been influenced by. I hear more and more people taking
up Subversion because of how pleasantly it works with the rails
development environment.

Professionally, I use subversion, though my team is looking to migrate
to something that does a better job at branch management and merging.
The verdict hasn't been given yet, but it will likely also be
distributed. Your review (and the reviews of others in this community)
might make an impact. I will likely give Perforce another shot (though
I know the team I work with is much more likely to want something open
source).

The important thing here is, for those of us who can afford to learn a
new tool (effort required here is usually exaggerated), the history of
a tool is a smaller barrier to entry (provided it works correctly). I
am much more likely to pick up an alternative in some of my projects
because of this.

> tried, and I have a hard time imagining how others would differ) the
> branches are physical copies in a different location. That's cheap for
> the making, yes, but your total storage cost goes up (since none of
> the advantages of having a single repository can be found) and it then
> becomes possible to *lose* branches from your repository (cf fragility
> above).

I have to admit that none of the people I work with write their code
in a Windows environment. In fact, as a team, we officially don't
support it. The only windows environments we have left are for testing
some of the web applications in Internet Explorer. This would probably
count as a bit of context I guess.

I will note that I've never had a branch problem, though I guess it
depends on how you manage your code. I usually have very little that
could be lost if I, for some reason, wanted to rm -rf a working copy.
I think most of this is helped by following a set of conventions for
each tool. There is a reason subversion makes use of the
trunk-tag-branch structure... and there are similar reasons that
people work certain ways with other tools. I usually have a couple
places I put code depending on the project type. In many cases, I
setup my environment with a central repository that represents
something like a trunk. Real development is done outside of the trunk
but synced in functional groups. Locally, small changes are recorded
quite often (this accentuates the power of cherry picking in an
interactive system). It seems that this duplication gives it the same
"relative" reliability that a standard Subversion setup would have
(detached code repo being one if you have multiple machines).

For cheap branches... I'm not sure either. It has always boggled my
mind why people are so upset when two files have to be duplicated. One
system that really does cheap branching well is git. Only a single
file with a few characters is created for each branch (initially,
changes are added of course). I'd love to hear from others who know
more about this.

> There's a lot of things to like about the *ideas* of DDSCM, but in the
> real world, I find that I'm rarely disconnected from the 'net long
> enough to care about the fact that I'm using a centralised management
> system.

True enough. I like some of the ideas because I am one of those people
who has experienced significant offline development. Maybe it
conditioned me to where I am now.

> So no, not a troll. Well informed using shorthands that should have
> been pretty easy to determine if you weren't blinkered by the
> proponents of DDSCM in the first place.

Yes. I know I lean far to the DDSCM side of things and I don't intend
to hide it. I think the quality of this reply made up for the
originally open claims. Though, I would like to ask, out of all the
problems you mention, none of them really give a benchmark that could
be used to note if a DDSCM would be ready under your definitions, are
there any specific things that could be fixed or done to make your
trust in a DDSCM system more likely? Or is DDSCM, for some reason,
mutually exclusive with what you get out of your current SCM usage?

Thanks,
Brian.

On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
> guess, though there is no denying that this number is larger than it
> should be). I think I will agree that the wide spread use is
> important, but I don't think adoption is the only metric to look at.

It's an important metric for the measure of the quality of the tool.
With more installations, it's significantly more likely bugs will be
reported and (hopefully) fixed.

> No argument here. There are a lot of projects that thrive off of easy
> entry. I think Ruby on Rails is an excellent example that many in this
> community have been influenced by. I hear more and more people taking
> up Subversion because of how pleasantly it works with the rails
> development environment.

I use Subversion primarily with RubyForge. I use Perforce at work. I
haven't yet decided what I'll do for stuff that isn't for RubyForge or
work; it's sort of sitting in limbo at the moment. (The decision will
*really* come when I change my home server.)

> Professionally, I use subversion, though my team is looking to migrate
> to something that does a better job at branch management and merging.
> The verdict hasn't been given yet, but it will likely also be
> distributed. Your review (and the reviews of others in this community)
> might make an impact. I will likely give Perforce another shot (though
> I know the team I work with is much more likely to want something open
> source).

Be warned: Perforce is NOT cheap. However, we had what seemed to be an
issue a few weeks back and they responded within four hours by email and
kept the case open for two weeks following up to make sure that we were
okay. I have nothing but praise for Perforce at this point. There's
occasional merge issues, but for my money p4v is perhaps the best
graphical interface for any SCM out there. If you've ever used
TortoiseSVN, it's got some nice features, but p4v gives me the ability
to see the diffs between any two revisions of a file dynamically
("time-lapse" view), which I use extensively when merging extensive
changes that even normal diff produces ugly files for.

That said, I still use the command-line tools extensively.

> I have to admit that none of the people I work with write their code
> in a Windows environment. In fact, as a team, we officially don't
> support it. The only windows environments we have left are for testing
> some of the web applications in Internet Explorer. This would probably
> count as a bit of context I guess.

Fair enough. However, the lack of a graphical tool for visualizing some
of the branching concepts is, IMO, significant.

> For cheap branches... I'm not sure either. It has always boggled my
> mind why people are so upset when two files have to be duplicated. One
> system that really does cheap branching well is git. Only a single
> file with a few characters is created for each branch (initially,
> changes are added of course). I'd love to hear from others who know
> more about this.

My issue is more with centralised backup of changes. At work we back up
a single machine and catch all of the committed changes. We're not yet
using cheap developer branches, but as we start using the absolute raw
power behind Perforce, you better believe we will.

I also expect to be looking at p4proxy for use at home with the work
server so that I can (hopefully) work disconnected without too much
trouble. I have to see how well that works.

> Yes. I know I lean far to the DDSCM side of things and I don't intend
> to hide it. I think the quality of this reply made up for the
> originally open claims. Though, I would like to ask, out of all the
> problems you mention, none of them really give a benchmark that could
> be used to note if a DDSCM would be ready under your definitions, are
> there any specific things that could be fixed or done to make your
> trust in a DDSCM system more likely? Or is DDSCM, for some reason,
> mutually exclusive with what you get out of your current SCM usage?

It's the auxiliary tools and the centralized source for knowing what's
going on with the source tree that matters to me. Patchset management is
possible with Perforce, although I can't tell you exactly how you'd do
it -- I haven't tried.

Give me a way to work with Perforce without constantly being connected
and I'll absolutely use it. But a DDSCM has to give me tools --
including GUI tools -- at least as good as and preferably better than
what Subversion gives me as well as an assurance that I will be able to
back everything up, then I will consider it. It also has to deal with
the reality that I develop on a lot of different platforms, including
Windows.

-austin

On 14 Mar 2007, at 20:46, Austin Ziegler wrote:
[snip]
> Distributed systems fit very few development models.
[snip]

Not true in my experience. Every place I've worked in the last couple
of years has had to deal with developers that don't always have
online access to the repo, or are in locations where connectivity
sucks so badly to their home location that it might as well not exist.

In fact every place I've every worked ever has had those problems -
its just that we only had solutions recently :-)

Don't get my wrong. I love Subversion. My home repo has been running
it for years and I'm in the process of moving $work over to it.

But I've been using SVK to as my primary client to access those
repositories for ages - and I wouldn't want to go back to not being
able to commit on the train :-)

Cheers,

Adrian

On Mar 14, 9:07 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:

> People say that distributed systems have cheap branching, but I find
> that very hard to believe, since (at least in the ones that I've
> tried, and I have a hard time imagining how others would differ) the
> branches are physical copies in a different location. That's cheap for
> the making, yes, but your total storage cost goes up (since none of
> the advantages of having a single repository can be found) and it then
> becomes possible to *lose* branches from your repository (cf fragility
> above).

I have actually given that some thought. While not the case presently,
I think eventually this will become a mute point. Ultimately file
systems themselves will manage data redundancy. I think of it as
"holographic" memory. I don't know why exactly as it has nothing much
to do with actual holographs, but it sounds cool ;-)

For fun I started writing a version control system in Ruby just to get
a better understanding of the concepts. Turns out not to be so hard
really --at least for a simple model.

In any case, as far your advice. I'm taking it, but with Matz' twist.
My two main projects consist of many subprojects. I figure I can use
Subversion on the project as a whole, but Git on each subproject. Well
that's the theory. Let you know how it goes.

T.

On Thu, Mar 15, 2007 at 04:26:52PM +0900, Trans wrote:
> > becomes possible to *lose* branches from your repository (cf fragility
> > above).
> 
> I have actually given that some thought. While not the case presently,
> I think eventually this will become a mute point. Ultimately file
> systems themselves will manage data redundancy. I think of it as
> "holographic" memory. I don't know why exactly as it has nothing much
> to do with actual holographs, but it sounds cool ;-)

The term "holographic", in reference to data storage and similar
subjects, refers to a three dimensional indexing system.  The term
"holographic memory" is already in use, generally involving
next-generation storage technologies that involve high density data
storage indexed three-dimensionally in photopolymers or crystalline
structures.

While I'm waxing pedantic, I may as well point out that the word you
wanted was probably "moot", not "mute".

On Mar 15, 4:17 am, Chad Perrin <per...@apotheon.com> wrote:
> > > becomes possible to *lose* branches from your repository (cf fragility
> "holographic memory" is already in use, generally involving
> next-generation storage technologies that involve high density data
> storage indexed three-dimensionally in photopolymers or crystalline
> structures.

Thanks. I'm aware. I'm using the term loosely, basically based on
concepts drawn from the book "The Holographic Universe" --the idea
that something thing can be in two different places at the same time.
I also view the the human brain something like holographic storage
using a form of reference and signal interference. In any case, I take
your point. I'm sure a better name already exists --I just don't know
what it is.

> While I'm waxing pedantic, I may as well point out that the word you
> wanted was probably "moot", not "mute".

Yep. I make that silly mistake all the time. But I'm a fan of Mark
Twain for more than one reason.

T.

On 3/15/07, Trans <transfire@gmail.com> wrote:
> I think eventually this will become a mute point. Ultimately file
> systems themselves will manage data redundancy. I think of it as
> "holographic" memory. I don't know why exactly as it has nothing much
> to do with actual holographs, but it sounds cool ;-)

As someone who works in the storage and backup industry, it will not
be a moot point.

> For fun I started writing a version control system in Ruby just to get
> a better understanding of the concepts. Turns out not to be so hard
> really --at least for a simple model.

That's actually what people think; it isn't, in fact, as simple as
people think it is once you start scaling. Git works for Linux because
it fits that specific development model. Other systems generally have
to be more flexible.

-austin

"Tim Becker" <a2800276@gmail.com> wrote/schrieb 
<254c7bfb0703121526r57c6d198t9234c5ad501a89f6@mail.gmail.com>:

> working offline is, with the exception of maybe a short stint on a
> plane or train, not that common nowadays.

Working offline is not the only situation where a distributed version
control system may be better. How about the following situation.

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.

In a distributed system A and B just pull from each other as often as
they need to get the task done. Full propagation (resp. integration,
in a central system) will follow then, but not earlier.

Regards
  Thomas

On Mar 18, 2007, at 5:45 PM, Thomas Hafner wrote:
> 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

Gary Wright wrote:
> - 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.

On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
> > > choices? Is it because SVN is more like CVS than the other choices?
> > Distributed systems fit very few development models.
>
> 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...

On 3/19/07, Robert Dober <robert.dober@gmail.com> wrote:
> > > > So I'm wondering, what's so special about SVN as opposed to the other
> > >
> > people such absolutes. So please, enlighten me.
>
> 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.

On 3/19/07, Brian Mitchell <binary42@gmail.com> wrote:
> > > >
> > > > don't transfer there.
> > > I think it is only fair that you share why if you plan on telling
> > BUT he is a very valuable contributor.
> fact that some people even question Matz sometimes about his thoughts
> 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

On 3/12/07, Trans <transfire@gmail.com> wrote:

>   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

On 3/19/07, Robert Dober <robert.dober@gmail.com> wrote:
> 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

On 3/19/07, Austin Ziegler <halostatue@gmail.com> wrote:
> I'm not sure what you're reading, Robert, but in no way am I a Unix
>                * austin@zieglers.ca
>
>
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

On 3/19/07, Austin Ziegler <halostatue@gmail.com> wrote:
> 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

> 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!]

On 21 Mar 2007, at 09:30, Mike Schwab wrote:

> 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

On 21 mar, 10:49, Adrian Howard <adri...@quietstars.com> wrote:
>
> 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

On 21 Mar 2007, at 15:30, Greg Hurrell wrote:

> 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

On 21 mar, 16:52, Adrian Howard <adri...@quietstars.com> wrote:
>
> That's basically it.

Many thanks for sharing.

Cheers,
Greg

On Monday 12 March 2007 10:51 pm, Brian Mitchell wrote:
> 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

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. :)

On Apr 2, 2007, at 20:51 , Kevin Williams wrote:

> Perforce is very good, but
> expensive.

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

On 4/2/07, Kevin Williams <kevwil@gmail.com> wrote:
> 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

On 4/3/07, Kevin Williams <kevwil@gmail.com> wrote:
> * fair security/authentication tools
> again, given the choice.
>
> 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

Michal Suchanek wrote:
> 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/

Jan Friedrich wrote:
> Trans schrieb:
> In subversion I have never create a branch: It was to expensive for me.

Well, it is cheap in git as it is in svn, the differences are not 
there...  The distributed/decentralised model is the biggest difference.

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

But having to renew the licenses every year is a PITA. (been there, done 
that for 5 years and saw the process getting more complicated over the 
years).

In the end, I switched over to Arch when they asked me to *fax* both the 
GPL and BSD license to them to get my renewed license...  Nuff said.

I've switched to Mercurial and won't come back ever to centralised 
systems like svn.

Ollivier Robert wrote:
> Well, it is cheap in git as it is in svn, the differences are not 
> there...
The main difference is for me that in svn the branch is a part of the 
hole history of the repository while in git a can simple delete a branch 
and it is not any more existent. Therefore I use it in many cases when I 
don't know if an idea is best way to solve a particular problem. If I 
want to do it this way, I merge it to the master and delete the 
temporary branch. Otherwise I delete the branch also and don't see it 
again. This is my definition of cheap: temporary branches.

On Tue, 3 Apr 2007 23:41:14 +0900, Ollivier Robert <keltia@gmail.com> 
wrote:
> Jan Friedrich wrote:
>> Trans schrieb:
>> In subversion I have never create a branch: It was to expensive for me.
> 
> Well, it is cheap in git as it is in svn, the differences are not
> there...

In my experience that isn't really true -- git has much better merge 
tracking than svn, so repeated merges on long-lived branches are 
substantially less painful with git.

-mental

On Apr 3, 2007, at 07:43 , Ollivier Robert wrote:

> Ryan Davis wrote:
>> Not entirely true. To be clear: Perforce licenses are FREE for open
>> source projects.
>
> But having to renew the licenses every year is a PITA.

It isn't _that_ much of a PITA for the benefits of using perforce for
free.

> (been there, done
> that for 5 years and saw the process getting more complicated over the
> years).

No, it is getting easier.

I've been running my perforce server for about 8 years running now
and while for a while they were indeed requiring a FAX of the license
application form their lawyers (behind the times as lawyers always
seem to be) finally realized the benefits of the electronic signature
act and accept email.

On Apr 3, 2007, at 05:13 , Austin Ziegler wrote:

> 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.

That is hard to do actually. At least, I haven't found any scripts
that do a good job of it (esp with continual/periodic updates). I'm
finishing up the last of the edge cases on my script to do just that
and will be releasing it "soon". I think all I have left is to delete
empty dirs in svn (which at this point I may just do by hand because
it isn't THAT big of a deal).

If you know of any good scripts for this, I'd love to look at them.

On 4/3/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>
> If you know of any good scripts for this, I'd love to look at them.

I'm not actually using Perforce at all for my OSS work, so I don't
have anything, sadly. I like hearing what you're saying, though, and
it'll be worth looking at when you release it.

-austin

"Austin Ziegler" <halostatue@gmail.com> writes:

> were to use Perforce myself, though, I'd set up a public read-only SVN
> repository for others to access.
>

I saw an interesting article about bazaar, which is meant to be a 
replacement
for subversion that is designed specifically for open source type 
projects
which have many different contributors/developers and is supposed to be 
easier
and more intuitive than subversion. It sounded interesting.

Tim

MenTaLguY wrote:
> In my experience that isn't really true -- git has much better merge 
> tracking than svn, so repeated merges on long-lived branches are 
> substantially less painful with git.

Yes, this is a major drawback of current svn (although svk sorta fixes 
that problem). svn has more problems anyway :-)

Disclaimer: I'm the author of a paper on using dVCS on FreeBSD with 
focus on Arch & Mercurial.

Ryan Davis wrote:
-> I've been running my perforce server for about 8 years running now
> and while for a while they were indeed requiring a FAX of the license
> application form their lawyers (behind the times as lawyers always
> seem to be) finally realized the benefits of the electronic signature
> act and accept email.

That's good for them.  I got hooked on dVCS when I switched to Arch then 
Mercurial so any centralised VCS is out in my book (and P4 is even more 
centralised than svn :-)).

On 4-Apr-07, at 8:38 AM, Ollivier Robert wrote:

> MenTaLguY wrote:
>> In my experience that isn't really true -- git has much better merge
>> tracking than svn, so repeated merges on long-lived branches are
>> substantially less painful with git.
>
> Yes, this is a major drawback of current svn (although svk sorta fixes
> that problem). svn has more problems anyway :-)
>
> Disclaimer: I'm the author of a paper on using dVCS on FreeBSD with
> focus on Arch & Mercurial.

Is this paper available anywhere?

Mike

--

Mike Stok <mike@stok.ca>
http://www.stok.ca/~mike/

The "`Stok' disclaimers" apply.

On Apr 4, 2007, at 05:40 , Ollivier Robert wrote:

> more
> centralised than svn :-)).

I'm totally fine with centralized VCS.

I'm even more fine with software that doesn't corrupt repositories,
is easy to back up, easy to understand, and works really well / stays
out of my way. Perforce is rock solid and has a long standing rock
solid history. I _have_ to have 100% complete trust in my VCS and its
backups. I simply can't say that about much of any other VCS out
there (except the nice stable old ones, like CVS). Too new. Too
buggy. Too experimental. Too full of agendas. I just want to get work
done.

> I'm totally fine with centralized VCS.
>
> I'm even more fine with software that doesn't corrupt repositories,
> is easy to back up, easy to understand, and works really well / stays
> out of my way. Perforce is rock solid and has a long standing rock
> solid history. I _have_ to have 100% complete trust in my VCS and its
> backups. I simply can't say that about much of any other VCS out
> there (except the nice stable old ones, like CVS). Too new. Too
> buggy. Too experimental. Too full of agendas. I just want to get work
> done.


To me, that only sounds like an argument against using Visual Source 
Safe ;)

As far as backing up an SVN repository (especially if it's using the
file system instead of BDB) tar does a pretty good job.

For the completely paranoid people that are afraid their backup will
be useless in 5 years because software will no longer be available, or
the current version won't read the old version, the svn source code is
small enough to be included on the backup disc.

On Apr 4, 2007, at 12:09 , Kyle Schmitt wrote:

> To me, that only sounds like an argument against using Visual  
> Source Safe ;)

Well, that's just a given.

> As far as backing up an SVN repository (especially if it's using the
> file system instead of BDB) tar does a pretty good job.

I think this is part of the problem. I don't want to think about what
storage mechanism it uses (past an evaluation stage at least). I
don't want to have to think: Did they test this storage format as
well as the previous? What are the repercussions of using this over
the other (eg http vs svn protocol)? I just want it to work so I can
do the same.

I've seen too much SVN corruption already to trust it.

Ryan Davis wrote:
> I've seen too much SVN corruption already to trust it.

Using the BDB store or files?

On Apr 4, 2007, at 19:30 , Clifford Heath wrote:

> Ryan Davis wrote:
>> I've seen too much SVN corruption already to trust it.
>
> Using the BDB store or files?

Should it matter? SVN corruption is SVN corruption.

That said, I dunno. I wasn't privy to the server's setup.

Ryan Davis wrote:
> On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
>> Ryan Davis wrote:
>>> I've seen too much SVN corruption already to trust it.
>> Using the BDB store or files?
> Should it matter?
Should? No. Does? Yes. http://tinyurl.com/39qetn (svnbook.red-bean.com)

Devin

On Apr 4, 2007, at 20:47 , Devin Mullins wrote:

> Ryan Davis wrote:
>> On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
>>> Ryan Davis wrote:
>>>> I've seen too much SVN corruption already to trust it.
>>> Using the BDB store or files?
>> Should it matter?
> Should? No. Does? Yes. http://tinyurl.com/39qetn (svnbook.red- 
> bean.com)

Does? No. ANY (recent) amount is too much. There are enough options
available where I don't need to pick from the scary ones.

On Apr 4, 2007, at 20:47 , Devin Mullins wrote:

> Ryan Davis wrote:
>> On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
>>> Ryan Davis wrote:
>>>> I've seen too much SVN corruption already to trust it.
>>> Using the BDB store or files?
>> Should it matter?
> Should? No. Does? Yes. http://tinyurl.com/39qetn (svnbook.red- 
> bean.com)

This is the last I'll speak on this topic. I promise...

% curl -s http://svn.collab.net/repos/svn/trunk/CHANGES | egrep -ic
"dataloss|corrupt"
16

Including... SURPRISE! In the very latest release!!! and 5 in the
last year alone (since sept 2006 actually).

So does the storage type matter??? Hell no. Not with that track record.

Ryan Davis wrote:
> % curl -s http://svn.collab.net/repos/svn/trunk/CHANGES | egrep -ic 
> "dataloss|corrupt"
> 16
> 
> Including... SURPRISE! In the very latest release!!! and 5 in the last 
> year alone (since sept 2006 actually).
> 

The only problem with Perforce is money.. Lots of them.
Of course in professional businesses it is a question
"money or safety". Sad that often money option wins..

As for private/small team use Subversion is quite good.
I've also been trying out Bazaar and it looks good too.

http://dentharg.wordpress.com/2007/02/14/bazaar-ng...

Cheers,
-Marcin

On 4/5/07, Marcin Gil <marcin.gil@nospamgmail.com> wrote:
> Ryan Davis wrote:
> > % curl -s http://svn.collab.net/repos/svn/trunk/CHANGES | egrep -ic
> > "dataloss|corrupt"
> > 16
> > Including... SURPRISE! In the very latest release!!! and 5 in the last
> > year alone (since sept 2006 actually).
> The only problem with Perforce is money.. Lots of them.
> Of course in professional businesses it is a question
> "money or safety". Sad that often money option wins..

1. For open source projects, Perforce can be free.
2. For commercial projects, it often is a matter of "you get what you
pay for." Part of the benefit of Perforce is rock-solid technical
support. You *pay* for the support in terms of a per-user annual
contract, but that doesn't change the quality of the support you get
(I am speaking from personal experience here).

There are things that you need to understand with Perforce, and i'm
sure we're not taking advantage of a quarter of what Perforce actually
offers us (and could probably boost performance without having boosted
the hardware), but if I were a company, I wouldn't want to use
anything else for my primary source repository.

-austin

Ryan Davis wrote:
>
> This is the last I'll speak on this topic. I promise...
>
> % curl -s http://svn.collab.net/repos/svn/trunk/CHANGES | egrep -ic 
> "dataloss|corrupt"
> 16
>
> Including... SURPRISE! In the very latest release!!! and 5 in the last 
> year alone (since sept 2006 actually).
>
> So does the storage type matter??? Hell no. Not with that track record.
Nothing is 100 percent free of data loss or corruption. Not Linux. Not
BSD. Not Windows. Not Solaris. And not *any* source code repository or
other application built upon them, free as in freedom, free as in beer
or expensive as all get out. This is why we RAID our disks and perform
frequent backups, live mirror if we need hot backup, and pay our
operations staff.

There are only two kinds of data in the world: those that have been
backed up and those that have not yet been lost.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given 
rabbits fire.

> Including... SURPRISE! In the very latest release!!! and 5 in the
> last year alone (since sept 2006 actually).
> 
> So does the storage type matter??? Hell no. Not with that track record.

As someone else said, every product has defects that can cause data 
corruption, including Perforce 
(http://public.perforce.com/public/perforce/faq/admin.html).  They 
wouldn't need recovery procedures for corrupted databases if they 
couldn't get corrupted.

What matters is how reliably the product performs in the real world. 
And that, barring some study proving it, is a personal opinion based on 
your experience and what others say of their experience.

On 4/4/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
> backups. I simply can't say that about much of any other VCS out
> there (except the nice stable old ones, like CVS).

Speaking as someone who was tasked with setting up and administering a
CVS server for a small team a couple years ago:

AHAHAHAHAHAHAHAHAHAHAHA.  CVS stable?  Trust CVS with your data?  That's 
rich.

I'm not saying any other system is necessarily better; but treating
CVS as some kind of gold standard of reliability is hilarious.  We're
talking about a system that can't even guarantee atomic commits.  And
for which maintenance releases sometimes randomly break major features
and have to be manually patched.  And which requires having a sysadmin
(or a knowledgeable user) around to periodically clean up orphan
lockfiles which break the repository.

The only thing CVS has going for it is that it is simple,
comparatively speaking.  And often that's the most important
consideration.  But it's only stable and reliable in comparison to
Visual Source Safe.

Believing that any information medium is infallable? Plain foolish.
Paper?
Magnetic tape?
Optical media?
Stone tablets?
Oil paint?

Software works on at least a few of these.
Software also operates under Murphy's law.
If you want a modicum of reliability, do like the military: multiple
redundancy!
That means use Raid Mirroring, on-site + off-site, use multiple systems?
Or best of all: don't be overly concerned about it. Accept the fact
that some versions saved will be corrupted and none will last
forever. Be realistic and plan for contingencies, but don't freak out
when they happen.