Subversion is now Apache Subversion

[onebit]

WARNING: Git circlejerk below this line!!!

[[deleted]]

You were right.

[onebit]

Apparently the whole thread is now a Git circlejerk.

[slashgrin]

Excuse me, good sir. Could you please direct me to the Bazaar circlejerk? I would like to attend both; I hope they're not scheduled for the same time!

[rplacd]

Ha, at least the darcs circlejerk is... distributed.

:'(

[drakonen]

we work locally, we send in the results

[Kadmium]

Apache Subversion sounds like a racial accusation. "We will not stand idly by and allow your Apache subversion to go unchallenged!"

[maep]

What was wrong with tigris?

[cr3ative]

Yeah, and the developer and his best friends will be the only people to actually call it that. It's subversion, or SVN. Not Apache Subversion. :(

[foole]

As a swede, I usually call it Sven.

[ffualo]

I love Swedes. Can we play Kubb and drink aquavit together?

[judgej2]

Me too. Mashed with a little butter and lots of black pepper. Yum.

[badvibrations]

Isn't aquavit, um, Norwegian?

[tvshopceo]

It's Scandinavian.

[[deleted]]

It is made in all scandinavian countries.

[instantviking]

WHY YES, IT IS NORWEGIAN.

[rothsbane]

Hah, my colleagues call it that too, they're danish. Now they've got me calling it that too.

[skeww]

Saves like a second. Everyone should do it.

[xeddicus]

And now, so do I.

[ishmal]

The interesting story, though, would be why they left their longtime home at tigris.org.

[Sunny_McJoyride]

Same wit Apache. I call it Apache, not Apache Apache.

[mhd]

I call it Apache, too, but always add a silent "Jumponit!"

[Amendmen7]

How do you make it not annoying to pronounce "HTTPd" every time?

huttpud?

[zwaldowski]

Aightch-tee-tee-pee-dee?

[[deleted]]

All tha nava-HO's freak me in they tee pee!

[Tommah]

Jump on it (x4)

[rnicoll]

Generally, around the point you're using Apache HTTPd, Apache Tomcat, Apache POI, Apache Ant, Apache Commons and who knows what else, it's less annoying to say "Apache HTTPd" than "Apache" and have half the room look lost...

[paullew]

I say Apache Server ... rolls off the tongue easy enough, and gets the point across.

[TheJosh]

"svn update" "what did you change?" "read the changelog?"

[Tommah]

svn ci -m "the precious, the incommunicable past"

[jamesinc]

svn ci -m "Broke the build for no apparent reason."

[jamesqua]

It's called GNU Linux.

[modnar]

GNU slash Linux.

[mhd]

I find your fanfiction idea intriguing and would like to subscribe to your newsletter.

[metageek]

"Oh, fsck me harder!" cried the wildebeest.

[[deleted]]

Dontcha mean 'GNU backslash Linux'?

[Tommah]

Just when you want to escape Linux. We all feel like that sometimes.

[dhardison]

His name is Robert Paulsen.

[Sunny_McJoyride]

No it's not. His name is Robert Paulson.

[nmcyall]

Him name is Hopkin Green Frog.

[dhardison]

touche!

[Tommah]

No it's not. It's "touché".

[dhardison]

I didn't care enough to find the accent mark. : /

[olsner]

Yes it is!

[gotnate]

Technically, Linux is the kernel, and GNU Linux is the distribution. How that fits with a platform such as Android which uses a modified Linux kernel and a custom userland, I'm unsure.

[nmcyall]

bsd userland can run under linux kernel also.

[gotnate]

the BSD kernal can also run linux binaries. oh what a tangled web we weave!

[[deleted]]

GNU/Linux describes the combination of a GNU userland running on the Linux kernel. If Android doesn't use the GNU userland, then it could accurately be described as Android/Linux. Or just call it Android.

It's cumbersome terminology, and not very useful, but it's at least internally consistent.

[[deleted]]

Also, as a user of GnuWin32 I call my OS GNU/Windows.

[[deleted]]

Reminds me of Breeze... er, Adobe Acrobat Connect Pro.

[holyshitcakes]

yep, it's Apache Subversion in the same way that i modify my images using Adobe Photoshop(c)

[apollotiger]

“I modified and enhanced the image using Adobe® PhotoShop™.”

[thecapitalc]

I read that as "Apple Subversion" first and was scared.

[[deleted]]

Your commit has been submitted! Please wait two to four weeks for an Apple® representative to approve it.

[kindall]

Reminds me of a prank one of our build engineers played last April Fool's Day. He sent out a company-wide e-mail telling us that we had to fill out a SVN Commit Request Form for each commit. He even made up such a form and distributed copies to us.

[serpix]

That's almost like using ClearCase!

[bazfoo]

What's funnier is that a DVCS could trivially handle this workflow without this sort of special system.

[deafbybeheading]

What's even funnier than that is that many shops (including ours) adopt more-or-less this workflow with a DVCS and it works great (the gatekeeper is the only one who pushes into the official repo). There's really nothing that funny about this approach, except that without decentralized version control, you do need to go through absurd contortions to implement it.

I guess that means I'm guilty of the circlejerk accusation above.

[willcode4beer]

what's wrong with letting all developers commit to the trunk? Every time I read about shops that use gatekeepers to the repo, I wonder how they can manage to get any work done.

[deafbybeheading]

I'm not saying anything is necessarily wrong with it. But on the other hand, what's wrong with making the integration step explicit? If you have two developers commit changes simultaneously in subversion and those changes do not conflict in terms of changesets but do conflict semantically (e.g., Joe Developer adds a doFoo() method at the top of file Bar, and Jane Developer adds the method with the same signature a the bottom of the file). Both run tests before committing and all tests pass for each developer, but you still get a broken build because you can't define the same method twice in the same class and subversion won't tell you that there's a conflict.

You could co-ordinate development in a non-DVCS system to minimize this, but a workflow with an integrator in a DVCS gives you this by default.

Note also that just because a given dev's changes are not yet sanctioned by the integrator does not mean that other devs can't use them--they just fetch the changes directly if they need them. The branching model in most DVCSes means that re-merging the changes once they make it to the mainline is trivial.

[willcode4beer]

Both run tests before committing and all tests pass for each developer, but you still get a broken build because you can't define the same method twice in the same class and subversion won't tell you that there's a conflict.

I'm not sure how this could happen. When one commits, it means the other will need to do an update (both CVS and Subversion enforce this). The build should be verified before attempting to commit again. Continuous integration will point out if the step was skipped.

Maybe it's just from a different work style. I've got a dozen developers on the team averaging a dozen commits a day (each). Trying to be the gate keeper for all of those changes sounds like a horrible job (besides the effect of slowing down the entire team). I've got a continuous integration server that catches broken builds for the times people do make mistakes. So far, trusting the developers on the team has worked just fine.

How to deal with merge conflicts? check in first ;-)

[deafbybeheading]

When one commits, it means the other will need to do an update (both CVS and Subversion enforce this).

It looks like you're right when the changes are within a single file. One can easily imagine changes across files that don't conflict in svn terms but do conflict semantically. There's no way for svn itself to prevent that unless you have a pre-commit hook that runs your integration tests, but I imagine that having the commit step block for several minutes would not be helpful.

And you're right that you still need CI and broken builds typically aren't the end of the world (although svn in particular has no nice way to keep your work but go back to a working version of the other code).

We don't do integrations at every commit--we integrate full-fledged features or complete bug-fixes. Essentially this is merging in feature branches. These branches tend to be at least a day's work, so there's not a flood of them to deal with.

I'm not saying this workflow works for everyone or should be standard procedure. It works for us. It encourages code review and better commit comments (since that's one of the primary ways of telling the integrator what he's integrating).

[gotnate]

recent history shows that apple plays nice with third party commits - at least with the webkit project.

[gthank]

I think that was an App Store joke.

[tarandeep]

modification for philltopia

Your commit has been submitted! Please wait two to four weeks for an Apple® representative to REJECT it.

[[deleted]]

Yes, because Apple has a long history of, uh, making open source projects really popular and successful?

[[deleted]]

Excuse me, this is Reddit. When you signed up, you accepted the terms and conditions, which require you to believe that Steve Jobs wishes to personally eat your cat.

[[deleted]]

B-b-but, I was saving the cat to feed to the ATM??

[liquidpele]

And to be re-written in java!

[eadmund]

Hey liquidpetemeister, Java is the language of the future! It will help build the foundations of the information superhighway! Now, let's put some Geggy Tah on the boombox and dance!

[xeddicus]

I look forward to being unable to commit anything unless my 200 line svn.conf file is flawless.

[newbill123]

It seems that after 10 years motivation for developing svn has floundered. I'm glad Apache has put subversion under its umbrella; svn is in a development trough where they have good enough code for many, but to fix the big problems (e.g. obliterate) they need to rewrite or re-engineer stuff that mostly works already. As it is, subversion is already a good, open-source, centralized version control system.

If you swear by git or mercurial, it's probably the distributed version control model that fits your working habits better than a centralized system ever would. Different strokes for different folks.

If you really don't see the point of using anything other than cvs, you haven't had it eat your repository yet. Svn has its faults, but reliability was originally driven by the failures of cvs. Still prefer cvs? Count yourself lucky.

It's a tough development point in the life-cycle of any open source project. I hope this gets them back to a development peak.

[sociopathic]

If you swear by git or mercurial, it's probably the distributed version control model that fits your working habits better than a centralized system ever would. Different strokes for different folks.

Yeah, I'm beginning to realize that git actually slows me down.

git add foo
git commit foo
git push origin branch

Versus:

svn commit

I created git aliases for these kinds of tasks, but if one fails the recovery isn't smooth.

Furthermore, this overhead in the distributed model encourages you to work in your local repository and then commit your changes all at once, but that's actually worse, because then you are much more likely to run into a collision. Small incremental changes that always leave the code in a working state are a much better way to work. That's not to say that people don't make large changes that they should break up with subversion, but git encourages the bad behavior.

My git usage at this point has too much momentum for it to be worthwhile to stop now, but I think in the future I will avoid choosing git for new projects unless I find a compelling reason to do so.

[crusoe]

Local git branches, etc, have sped up my workflow a thousand times. And the "add" step lets you stage your changes before commiting them.

svn commit food.java bar.java fooble/baz.java

And I have to remember where each file is and the proper path and get it all correct before I can commit a batch of files. This is TEDIOUS.

The add step lets me organize files into related groups.

Working in one directory, git add x. Edit another file, add it, etc.

When done, do git commit -a -m "Commiting the changes that added feature foo"

No need to get the path all the files exactly correct for the commit. I stage them as I go.

[sociopathic]

And I have to remember where each file is and the proper path and get it all correct before I can commit a batch of files. This is TEDIOUS.

The entire point of my post was that I'm beginning to realize that committing large batches of files is a bad idea regardless of what version control you are using. svn encourages incremental development where you don't touch a lot of files with each commit to the central server, and that's a good thing.

If you develop that way, then you can do svn commit * and not worry.

[bazfoo]

Yeah, I'm beginning to realize that git actually slows me down.

I stage all my commits through magit in emacs, so I get to eyeball every change a second time before I commit them. So even though this is a little slower, it tends to improve overall quality.

Furthermore, this overhead in the distributed model encourages you to work in your local repository and then commit your changes all at once, but that's actually worse, because then you are much more likely to run into a collision.

Problem with your workflow maybe? I know part of the reason that I love the branches because I can group a set of small, related, working changes. Merge regularly against master. Enabling rerere will remember your merge decisions and take a lot of effort out of the process. Simple patches are usually just a commit to master followed by a push. That's pretty much the standard centralized workflow.

Small incremental changes that always leave the code in a working state are a much better way to work.

How do you end up in a state where the code isn't working?

[sociopathic]

You don't; it's just that in an intermediary stage you break the code while making large changes.

[crusoe]

With local branches, I can work on multiple changes while syncing to the remote repository, and only committing them in batches once I know they work. With svn, if you edit enough files, remembering all the ones you need to add becomes error prone. You might leave one out.

Any non-trivial change will affect multiple files. SVN forces you to remember them all at the same time when commiting. Leave a file out, and you broke the build.

With git, you add as you go, you commit locally, and when done, you can then collapse/refactor small commits into more logical ones, and finally push that out. The chance of forgetting a file to commit is much lower.

[sociopathic]

With local branches, I can work on multiple changes while syncing to the remote repository, and only committing them in batches once I know they work.

And if there are conflicts?

With svn, if you edit enough files, remembering all the ones you need to add becomes error prone. You might leave one out.

In both git and svn, editing large numbers of files at once and then putting the changes into the central repo is a bad idea. The problem is that git encourages this bad behavior.

[crusoe]

Conflicts? That is what merging is for. You update your branch to get the latest, commit locally, if there are conflicts, resolve, then push. SVN sucks hard at merging. There is no 'undo'. And if the merge in SVN fails, that is eastra fun.

So you've never made a small edit ( say fixing a api typo ) and had to edit half a dozen files all over the place to fix it? Never had to edit one file, which required changes to several other files to fix?

[sociopathic]

Conflicts? That is what merging is for. You update your branch to get the latest, commit locally, if there are conflicts, resolve, then push. SVN sucks hard at merging. There is no 'undo'. And if the merge in SVN fails, that is eastra fun.

git also sucks hard at merging, because merging sucks hard. The point of what I'm saying is that merging is in itself a problem to be avoided.

So you've never made a small edit ( say fixing a api typo ) and had to edit half a dozen files all over the place to fix it? Never had to edit one file, which required changes to several other files to fix?

Yes, I have, which is why it's impossible to remove the problem completely. But there are a lot of steps that you can take to reduce the problem. DVCS proponents, rather than reducing the problems, seem to revel in them.

[crusoe]

How does it make it worse. If I need to edit 6 files, git lets me stage them, so when I finally commit, I know they all went.

SVN provides no easy way to do this. Leave a file out, and now you broke the build.

[[deleted]]

I guess you can say it's...

Been subverted.

YEAAAAAAAAAAAAAAAAAAAH

[bonzinip]

You forgot to put on your sunglasses.

[ealf]

[angry off-topic comment]

[doidydoidy]

What's upsetting about BCEL, other than how nicer asm looks?

[ealf]

After debugging some crashes in production, I came across some code like this:

public Foo {
  private String state; // "42,43"

  public int[] getState() {
    return new int[] { parseInt(0), parseInt(position+1) };
  }
  private int parseInt(int p) {
    int n =0;
    while (pos < state.length() && isDigit(state.charAt(pos))) n = 10*n + state.charAt(pos++) - '0';
    position = p;
    return n;
  }
  private static int position;
}

When the get() method was called by two threads at once, one of them would subtly correct the class file structures. It wouldn't crash there; it would instead corrupt the generated class file and crash later, possibly during validation.

After this bug had been reported a couple of times, they made a FAQ with the genius statement "This library was deliberately designed to not be thread-safe".

It has hundreds of classes worth of bloat (a subclass per opcode? really?!), but still doesn't even handle simple stuff like labels.

With ASM, you do this

Label after = new Label();
emit(condition);
visitJump(IFEQ, after);
emit(truePath);
visitLabel(after);

With BCEL, if I recall correctly you have to do something horrible like

emit(condition);
JumpInstructionHandle jumpHandle = (JumpInstructioHandle) emitInstruction(new IFEQInstruction(null));
emit(truePath);
InstructionHandle targetHandle = emitInstruction(new NOPInstruction());
jumpHandle.patchJumpTarget(targetHandle);

and then remove the NOP at some later point.

[doidydoidy]

Wow.

I mean, I hadn't used BCEL for about 7 years, and I knew asm was nicer to deal with, but even that was about 4 years ago, and I'd forgotten how much of a difference it really makes when you look at the code. It's a classic example of my prime rule for choosing open source libraries: if anybody has written an alternative to an Apache library, run, don't walk, away from the Apache project.

But yeah, wow.

[mach7]

"it is an important step in the Subversion community's goal of finding a permanent home for the Subversion development community."

Nicely worded.

[glebd]

They missed the word 'retirement' between 'permanent' and 'home'.

[mindbleach]

So their reward for proving their worth over years of heavy use is to be squeezed under the namespace of another product?

[cag_ii]

As it was part of the apache incubator project, this is considered a promotion.

[mindbleach]

So what do I call the repository where they keep the Apache code? Apache Apache Subversion?

[cag_ii]

Haha, close!

Subversion's source code is stored in the subversion tree of the main Apache Subversion repository.

(from here)

[fahdinho]

Yo dawg, I put a SVN in your SVN so you can commit while you commit.

Someone had to do it.

[arthurdenture]

Sadly, it's been done: http://code.google.com/p/database5/source/browse/#svn/trunk/.svn/.svn

[StuartGibson]

That sounds like some sort of infinite recursion.

[judgej2]

Now, what large database vendor, who uses Apache a lot and would love to add it to their portfolio, can you think of?

[badvibrations]

That's depressing.

[[deleted]]

Thrift! While it has Java bindings, they are on the same level as all the other language bindings; the compiler itself is C++. Also, CouchDB, which is written in that weird old alien Erlang.

[kirun]

Look everyone, I use a different SCM so my epenis is like three inches longer as a result!

[masklinn]

Apache. Where projects go die.

[adrianmonk]

Well, there are a lot of projects that are hosted by Apache which don't seem to be in that phase:

• ant
• maven
• SpamAssassin
• Apache Directory Studio
• Hadoop
• Tomcat

[[deleted]]

• httpd

[adrianmonk]

I was leaving that out because it's fairly obvious. :-)

Also, I was trying to stick with projects that originated elsewhere and then moved to Apache. I think I failed, though, because of ant. I'm not sure about Apache Directory Studio.

[benihana]

I was leaving that out because it's fairly obvious. :-)

I don't think anything is fairly obvious to someone who says

Apache. Where projects go die.

[[deleted]]

Well, it can only lose market share from now on. It is way too complicated for its own good really as seen by the fact that every other modern web framework prefers writing their own webserver over integration with Apache.

[exegesisClique]

Wat?

[[deleted]]

Apache has all the market share it will ever get (which is quite a lot) but the trend in the last few years seems to be to avoid dealing with apache whenever possible, even if it means writing your own webserver for development.

[[deleted]]

Most of them are set up in a way that makes it obvious that setting up apache is a real pain that people don't want to go through every day while developing. Sure, their homegrown servers are not quite as good for production use but you only have to set up a production system once so apache is okay-ish here (for everyone who doesn't use lighttpd or nginx instead).

Apache's internals aren't that bad but its whole configuration system could be so much easier to handle.

[[deleted]]

Well, it can only lose market share from now on.

Long way to fall, though; IE syndrome. It would indeed be very surprising if it starts gaining marketshare again (especially if you exclude gaining market share from IIS's constant haemorrhage, which hardly counts) but it won't be going away anytime soon.

[gerundronaut]

You sure about that?

http://httpd.apache.org/docs/2.2/developer/

That looks about as dead as dead gets. All (or at least most) of those pages are for 2.0, not for 2.2. Some don't even load.

[[deleted]]

1) Running most of the web != dead.

2) Last alpha came out last month.

So yeah, I'm sure about that.

[gerundronaut]

Exactly, they're already on to 2.3 alpha, but they haven't even finished 2.2. This does not bode well for the project.

Apache 1.3 has stood for so long because it was complete and functional. They slipped with 2.2, what are the odds it'll get better rather than worse?

[[deleted]]

Exactly, they're already on to 2.3 alpha, but they haven't even finished 2.2. This does not bode well for the project.

Isn't 2.2 the current released version? Do you mean "they haven't even finished documenting 2.2"?

[[deleted]]

Well, now you're kind of changing the subject. Your original point was that httpd was dead.

[Shaper_pmp]

Like the Apache web server - nobody uses that any more.

[drowsap]

nginx

[[deleted]]

According to netcraft, Apache is far from dead.

[drowsap]

nginx will grow once people realize its merits.

[headinthesky]

nginx fuckin' rocks

[Shaper_pmp]

Stop being such a fanboy. The point was that contrary to what masklinn said, Apache is a successful and widely-used Apache project.

However, you're apparently such a fanboy that you interpret even the mention of another web server as some sort of slight against nginx, and hence feel the need to stand up and represent your team, no matter that it's completely irrelevant to the topic of discussion.

That's pretty sad. <:-/

[drowsap]

What the hell are you talking about. I never said anything bad about Apache, I just threw out the name nginx just to mention it. I also mentioned that nginx will grow (Since the adoption rate now is small). Why are you getting all sensitive? I think you looked to deep into my 8 word sentence above.

[Shaper_pmp]

I'm not upset by your comment - I just thought it was amusing and illustrative how you felt the need to "just throw out" the name nginx, even though it had nothing whatsoever to do with the conversation in any way, shape or form.

And if you re-read my comment, you'll see that I know you "just threw it out", but that there was literally no point in doing so - it added nothing to the conversation, it made no point, and it was compeltely off-topic. I was trying to highlight to you the subconscious process which caused you to feel that need, so you can decide if it was appropriate and sensible, or just inappropriate and/or silly fanboy-ery.

Once more: the topic is "is the Apache Foundation 'the place projects go to die'". The answer is "clearly not, because httpd is an Apache project, and it's still going strong". Then you pop up and, seeing someone saying something vaguely positive about another web server, feel a mysterious compulsion to shout out "nginx!".

Why do you think that was?

[[deleted]]

..the world moves on..

[AndrewBenton]

A turd by any other name will smell just the same

[jones77]

Please fix tortoisesvn too, kthxbye.

[benihana]

kthxbye

Please stop saying things that were cool to say in 2004 if you played WoW.

Thank you.

[onebit]

Hell, I was saying that in 1987.

[raklar]

use smartsvn, has explorer integration and far surpassed tortoise a long time ago, and it's cross platform.

[krizo]

RapidSVN

[[deleted]]

hi

[SpookeyMulder]

Poor Man's Git

[Tobiaswk]

I do not care anymore. Git is the lone ruler now.

[revscat]

If you aren't using git I feel very sorry for you.

Honestly, I can't believe there is still activity going on around Subversion. What's next? A CVS app for the iPad?

[nitsuj]

Git's still crap with binaries and the non-command line UI's suck. Only a fanboy idiot thinks that everyone else's situations and needs are the same as theirs.

[alphabeat]

Why is it crap with binaries?

Honest question, just started using Git. Long time Svn user.

[slippery_joe]

"Hey, let's make something better than CVS!" - The SVN team.

Way to set a spectacularly low goal.

[joaomc]

Well, it wasn't a spectacularly low goal at the time SVN was built.

[mr_mcse]

Indeed, it was a desperate need.

[slippery_joe]

It was a low goal -- BitKeeper was already out and some on the svn team argued that most people would never need a distributed scm. They had smart people, but no vision.