Why SVN?

ruby-talk
41

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 :wink:
). 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, Robert Dober <robert.dober@gmail.com> wrote:

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

42

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

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

43

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 :slight_smile:

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

···

--
Posted via http://www.ruby-forum.com/\.

44

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 Mar 12, 2007, at 6:13 PM, Jeremy Tregunna wrote:

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

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

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.

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.

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

45

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.

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 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

46

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 Thu, Mar 15, 2007 at 04:26:52PM +0900, Trans wrote:

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 :wink:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent: a Signify v1.14 production from http://www.debian.org/

47

> 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 :wink:

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

···

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

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

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

48

Gary Wright wrote:

···

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

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.

--
Glen

49

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

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

Thanks,
Brian.

Robert

···

On 3/19/07, Brian Mitchell <binary42@gmail.com> wrote:

On 3/19/07, Robert Dober <robert.dober@gmail.com> wrote:
> On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
> > On 3/14/07, Austin Ziegler <halostatue@gmail.com> wrote:
> > > On 3/12/07, Trans <transfire@gmail.com> wrote:

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

50

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:

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
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

51

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

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

···

On 3/19/07, Austin Ziegler <halostatue@gmail.com> wrote:

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.

52

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

···

--
Posted via http://www.ruby-forum.com/\.

53

Is this paper available anywhere?

Mike

···

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 :slight_smile:

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

--

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

The "`Stok' disclaimers" apply.

54

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 12-Mar-07, at 8:05 PM, James Edward Gray II wrote:

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

James Edward Gray II

!DSPAM:45f5ead6216871342211937!

55

> 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

56

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

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

57

> > 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 :wink:

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.

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 Mar 15, 4:17 am, Chad Perrin <per...@apotheon.com> wrote:

On Thu, Mar 15, 2007 at 04:26:52PM +0900, Trans wrote:
> On Mar 14, 9:07 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:

58

[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 2007, at 09:30, Mike Schwab wrote:

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

59

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 3/12/07, Jeremy Tregunna <jtregunna@blurgle.ca> wrote:

On 12-Mar-07, at 8:05 PM, James Edward Gray II wrote:
> 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).

60

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

···

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.