svn clients

[fronty]

Code: Select all

wget http://subversion.tigris.org/downloads/subversion-1.6.2.tar.gz
tar -xzf subversion-1.6.2.tar.gz
cd subversion-1.6.2
./configure
make
sudo make install

Code: Select all

cd /usr/ports/devel/subversion
make install clean

Why do things by hand when you can get same (or better) results with automated system?

[Solar]

Code: Select all

wget http://subversion.tigris.org/downloads/subversion-1.6.2.tar.gz
tar -xzf subversion-1.6.2.tar.gz
cd subversion-1.6.2
./configure
make
sudo make install

Oh yeah? Oh yeah?

/me cracks his knuckles.

Code: Select all

$ emerge --pretend --verbose subversion
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] dev-util/subversion-1.5.5  USE="apache2 berkdb dso java nls perl python sasl vim-syntax webdav-neon -bash-completion -debug -doc -emacs -extras -ruby -webdav-serf" 4,825 kB

Total: 1 package (1 reinstall), Size of downloads: 4,825 kB

Do you want the documentation and Ruby bindings to go with that?

Code: Select all

$ sudo echo "dev-util/subversion doc ruby" >> /etc/portage/package.use && emerge subversion

There, sucker!


(Just making fun here. There's nothing better than a bit of "my way of doing things is better than yours" from time to time. )

[pcmattman]

Of course, your way requires "emerge".

Mine only requires a bash-compatible shell for the configure script, make, wget, tar, and a decent build environment, which makes it doable on even a hobby OS

[Solar]

I'm absolutely in the mood to carry on, but I think we're OT enough as it is.

[steveklabnik]

Hey you attempted humour! good for you!

Hey, I giggled. Whatever.

And mikkop92 is right, I was only half joking. If I had the choice, I'd just use git-svn. Besides, unless you're not the one calling the shots, there's absolutely no reason to keep using a non-distributed SCM system. Use hg, darcs, bzr, whatever you want... but svn?

[Solar]

Besides, unless you're not the one calling the shots, there's absolutely no reason to keep using a non-distributed SCM system. Use hg, darcs, bzr, whatever you want... but svn?

Oh, there are several reasons, IMHO. Complexity, quality of documentation, attitude of lead programmer.

Git and its ilk are perfect for huge, massive-concurrently projects like the Linux kernel. For everything you'd do on a hobby level, Subversion is absolutely enough. (How often do you expect to branch your own project?)

[steveklabnik]

Complexity

Unsubstantiated. As long as you're not an idiot, git is not difficult.

Okay, okay, that may be a bit harsh. Let's compare basic svn usage to basic git usage:

svn co svn+ssh://path/to/your/repo .
*edit files*
svn commit -m "message, lol"
svn up

git clone git://path/to/your/repo
*edit files*
git commit -a -m "message, lol"
git pull

Yes. Much harder.

quality of documentation

I have never had a problem with this, ever. Maybe this was true in the past, but today? Hardly.

attitude of lead programmer

I evaluate the software that I use by its technical merits, not by who wrote it or how much I like them. (By the way, that talk is actually what convinced me to actually learn more about git and how it works, and got me started with git in general. Guess we have slightly different perspectives on things, huh?)

Git and its ilk are perfect for huge, massive-concurrently projects like the Linux kernel.

We agree!

For everything you'd do on a hobby level, Subversion is absolutely enough.

We disagree! I don't know why you'd want to intentionally use an inferior tool. git is a superset of svn. It can do everything that svn can do, and more. There's no reason to use inferior software if you don't have to.

(How often do you expect to branch your own project?)

I branch for every feature. I'm not even kidding. If you're curious, you can find out about the workflow that I use on the documentation for using git with XOmB that I wrote.

[Kevin]

Git and its ilk are perfect for huge, massive-concurrently projects like the Linux kernel. For everything you'd do on a hobby level, Subversion is absolutely enough. (How often do you expect to branch your own project?)

You don't branch in SVN, because it's hard (okay, branching is not, but merging is). Instead you probably use something on top like quilt to avoid the choice between having to clutter your history with incomplete commits that don't ever work or not using version control at all until the change is perfect.

With git you do have sensible branches, so you just use them. Commit, amend, edit the changes until they are ready and only then merge them back then. I always work in branches for tyndur which I would clearly see as "hobby level".

[Solar]

Complexity

Unsubstantiated. As long as you're not an idiot, git is not difficult.

And here, ladies and gentlemen, we see how attitude of lead programmer can actually permeate all the way through to the user base.

Sorry, that was a bit harsh, too.

I'm not an idiot, and I don't like how your statement implies me to be one simply because I do not agree with you. I wouldn't even say that git is difficult for a tool that does what git does. But git does more than SVN, so yes, git is more difficult than SVN, especially if the additional features are exactly what I would never use anyway.

svn co svn+ssh://path/to/your/repo .
*edit files*
svn commit -m "message, lol"
svn up

git clone git://path/to/your/repo
*edit files*
git commit -a -m "message, lol"
git pull

Yes. Much harder.

Perhaps, perhaps not. What's this "git clone", and how is it different from "git checkout"? You know, I'm a dinosaur, and perhaps an idiot, too, but every VCS I have used so far used "checkout" (or "co"), so what's this "clone" about?

(Yes, I'm playing the dofus here, but perhaps you get my meaning.)

I evaluate the software that I use by its technical merits, not by who wrote it or how much I like them.

I use a mixture of the two. I like UltraEdit not only because it's probably the best text editor I've used so far, but because I found the lead programmer to be a friendly, responsive guy who reacts well to costructive criticism. I dislike the Linux kernel not only because of some technical issues, but because of the attitude of those involved, too.

But this is only a very minor point. In the comparison of SVN vs. git, other factors are much more important.

I don't know why you'd want to intentionally use an inferior tool.

Mostly because I don't consider SVN to be inferior, merely different.

Then there's a whole number of reasons. I've used SVN (and before that CVS and before that RCS) for as long as I used VCS. I've got a SVN server up and running. I like the Trac Wiki / BugTracker / SourceBrowser frontend very much, and got that up and running, too. I am very familiar with both the server and the client set-up. My company uses SVN for all its repositories, too.

I don't know about you, but I switch only when I actually see a benefit in doing so, not because there's shiny new technology to be had.

git is a superset of svn. It can do everything that svn can do, and more. There's no reason to use inferior software if you don't have to.

What git offers in addition to svn - clone, pull, merging, etc. - is exactly that part of git I would never use. So why bother setting up a superset if what I have fits the bill?

And again that completely uncalled-for side remark making the whole discussion rather pointless because I'm an idiot anyway, right?

I branch for every feature. I'm not even kidding.

I absolutely believe you. But are you doing that because it's the best way to do it, or because it's the way heralded by the tool you use?

I work at only one feature at a time, and tag a new release when I'm done. If I have to do maintenance on a previous release that cannot wait till the next one, I make a branch. And I never do automatic merges. Everything that's not a pure whitespace edit gets reviewed. I won't go into details here, but it's a conscious decision both by me and my superior due to the nature of the software I work with. In the business reality, there are many non-technical factors driving a decision for one workflow or another...

You don't branch in SVN, because it's hard (okay, branching is not, but merging is). Instead you probably use something on top like quilt to avoid the choice between having to clutter your history with incomplete commits that don't ever work or not using version control at all until the change is perfect.

I don't branch (often) in SVN because I consider a branch to be a sign of previous work not well done, and another needless complexity in your source tree. Your projects might differ, you might be happy with git, that's absolutely OK. But my opinion holds, you don't need git or its branch-and-merge workflow for a hobby project.

[Kevin]

I don't branch (often) in SVN because I consider a branch to be a sign of previous work not well done, and another needless complexity in your source tree.

Well, development branches are not about previous work, but about future extensions. But if you want to stick with the "work not well done", I admit that when preparing a patch series I usually don't get it right in the first attempt. So I don't want to have each step set in stone when I'm starting with the next one because I only know if it was completely right when the whole thing is done. This is what I used to use quilt for in SVN times and what I'm using git branches for now.

So for me git matches my workflow better (I don't need external tools on top any more), your workflow might differ. (Oh, and being used to SVN/not having used git yet is a perfectly valid personal motivation not to switch, but it's not a good point in an objective comparison)

But my opinion holds, you don't need git or its branch-and-merge workflow for a hobby project.

Let me change that a bit: "You don't need git or its branch-and-merge workflow for every hobby project, but for a lot of projects it makes perfect sense".

[Solar]

But my opinion holds, you don't need git or its branch-and-merge workflow for a hobby project.

Let me change that a bit: "You don't need git or its branch-and-merge workflow for every hobby project, but for a lot of projects it makes perfect sense".

"Some", and we have a deal.

[earlz]

well that was interesting.. lol

I personally have not looked into git, and don't much care, I've very happy with SVN and don't see any point in changing anytime soon..

I also use svn at the command line, with their official client. Switching from Turtoise and CL is really not too difficult.. well not on most things.. you just have to remember right-click>svn>commit == svn commit lol oh.. .but you do miss the whole merging helper thing, which is pretty handy IMO.. but not a necessity and can easily be replaced by other things in *nixs..

[01000101]

I honestly don't care all that much between the two... as long as "the two" doesn't ever include Mercurial (hg).

*shudders*

[steveklabnik]

And here, ladies and gentlemen, we see how attitude of lead programmer can actually permeate all the way through to the user base.

It's not really that, I'm just another really opinionated person.

I'm not an idiot, and I don't like how your statement implies me to be one simply because I do not agree with you.

I never called you an idiot. I know from your posts that you know quite a bit. Also, I didn't call anyone an idiot because they don't agree with me, I called them an idiot if they can't grasp git. There's a difference.

I wouldn't even say that git is difficult for a tool that does what git does. But git does more than SVN, so yes, git is more difficult than SVN, especially if the additional features are exactly what I would never use anyway.

It's not more difficult. It has more options. The extra options are 'difficult' in the sense that svn doesn't even have the options at all.

If git is more difficult than svn because of "features you wouldn't use anyway," then git wouldn't be harder for you, now would it?

Perhaps, perhaps not. What's this "git clone", and how is it different from "git checkout"? You know, I'm a dinosaur, and perhaps an idiot, too, but every VCS I have used so far used "checkout" (or "co"), so what's this "clone" about?

(Yes, I'm playing the dofus here, but perhaps you get my meaning.)

Git actually has a 'checkout' operation, but 'clone' is more useful, because hey, it does more. You can 'git co' all you want. .

In any case, you're using a different piece of software. When I switch between two text editors, I don't expect them to work 100% the same way, I expect them to be slightly different from each other... 'clone' vs 'co' is one of those things that's slightly different.

I use a mixture of the two. I like UltraEdit not only because it's probably the best text editor I've used so far, but because I found the lead programmer to be a friendly, responsive guy who reacts well to costructive criticism. I dislike the Linux kernel not only because of some technical issues, but because of the attitude of those involved, too.

I'm not going to say that a good community is a bad thing. Far from it. It's one of the reasons that I enjoy Haskell hacking as much as I do. But don't let your distaste of Linus stop you from using great software.

Mostly because I don't consider SVN to be inferior, merely different.

You are free to have incorrect opinions. I won't argue with you about them. Just be aware that you're wrong.

I don't know about you, but I switch only when I actually see a benefit in doing so, not because there's shiny new technology to be had.

I totally agree. Switching for the sake of switching is a silly thing to do. But even for just offline commits, that's one super huge important useful feature right there. That alone was enough to get me to switch.

What git offers in addition to svn - clone, pull, merging, etc. - is exactly that part of git I would never use. So why bother setting up a superset if what I have fits the bill?

That's fine. Just be aware that by virtue of you only needing a butter knife and not a chainsaw, the butter knife isn't "just different" than the chainsaw.

And again that completely uncalled-for side remark making the whole discussion rather pointless because I'm an idiot anyway, right?

Not at all. I do not believe that you're an idiot. But this whole, "programming is hard, let's go shopping!" attitude is bad for CS as a whole. Don't shy away from hard things! You'll find out that they're not even really hard, you just think they are.

I honestly don't care all that much between the two... as long as "the two" doesn't ever include Mercurial (hg).

*shudders*

I've only ever heard good things about hg. What didn't you like about it?

[Solar]

Mostly because I don't consider SVN to be inferior, merely different.

You are free to have incorrect opinions. I won't argue with you about them. Just be aware that you're wrong.

Nice attitude.

But even for just offline commits, that's one super huge important useful feature right there. That alone was enough to get me to switch.

Again, a feature I don't need. Offline diffs, now, that'd be something I'd miss sorely, but SVN has them.

That's fine. Just be aware that by virtue of you only needing a butter knife and not a chainsaw, the butter knife isn't "just different" than the chainsaw.

Yes it is, and thank you for the excellent metaphor. When did you last butter your breakfast bread with a chainsaw?

I do not believe that you're an idiot. But this whole, "programming is hard, let's go shopping!" attitude is bad for CS as a whole. Don't shy away from hard things! You'll find out that they're not even really hard, you just think they are.

I prefer to focus on the hard things that are part of the problem - like, the next bug - instead of the solution - like, a versioning system that's overkill for my needs.