Slashdot Mirror

Assuming you already have svn installed and copy of Apache httpd with mod_dav_svn and you are are running on some flavor of *NIX.

Create an svn repository somewhere, eg.

# svnadmin create /opt/svn-repo

Create a password for your repo, replace username and password as appropriate

# htpasswd /opt/svn-repo/conf/htpasswd USERNAME PASSWORD
# chmod 640 /opt/svn-repo/conf/htpasswd

Fix the permissions of the repo so that the user that httpd runs as can write to the repo database. Replace www with whatever the appropriate user is:

# cd /opt/svn-repo
# chgrp -R www .
# chmod -R g+r .
# chmod -R g+rwX db locks
# find db locks -type d -exec chmod g+s '{}' ';'

Open httpd.conf and add/uncomment the following lines in the LoadModule section:

LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so

At the very bottom of your httpd, add a location for your repository:

<Location /repo>
    DAV svn
    SVNPath /opt/svn-repo
    SVNAutoversioning on

    AuthType Basic
    AuthName "Subversion repository"
    AuthUserFile /opt/svn-repo/conf/htpasswd

    Require valid-user
</Location>

Restart apache and then test your config:

    # svn ls http://localhost/repo --username USERNAME --password PASSWORD --no-auth-cache
    #

No errors means everything is working.

See the manual for instructions on mounting the WebDAV share with various clients. Note that Windows is kind of problematic for this out of the box and you may need to use a third party file system driver such as NetDrive.

Svn blame or git blame is your friend

We are going to be using it with software qa metrics to work out who is generating the most problematic code.

http://svnbook.red-bean.com/en...

http://git-scm.com/docs/git-bl...

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!

Honestly I don't care; I was more pointing to the fact that I believe it came from Git. I couldn't easily find a reference of the term for the SVN 1.4 docs; but it was there in the 1.5 docs - which would have been well after Git was established, so the SVN Red-Book authors adopted the term; I haven't really seen it used on the SVN mailing lists at all. That's all.

In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation

I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.

The SVN Merge Tracking introduced in SVN 1.5 does very well with keeping those things straight, and makes it quite reliable.

The problem prior to SVN 1.5 was that you had to track all the merges yourself and be very careful about how you merged. It wasn't that SVN was incapable of it, just that it was a big PITA to do it and know that you didn't double merge something. SVN 1.5 introduced Merge Tracking which has kept increasing in its smarts since - 1.5 already did the case of change A:B being done in one revision and changeset C:D in another, whether C:D came after A:B (e.g A < B < C < D) or even where it contained A:B within it (e.g C < A < B < D).

I generally don't worry about merges any more; I just do them and verify the result is what I intended - sometimes adding an extra log message in a file, or modifying a version number, and that's really about it.

Of course I almost always do a dry run (test merge) in order to know what to expect; and the only time I have seen where people have gotten into trouble with merges is when they fail to do the Double Merge - e.g Merge from destination to source, then source to Destination - when its all complete (e.g. for the reintegration merge).

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!

In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation

I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.

You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.

I have done that without any issues, as I am sure many on the SVN mailing lists have as well - both before and after the Merge Tracking was added. It's a natural part of the work flow. I can think of no SVN rules that it violates. In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation (see the section Keeping a Branch in Sync Without Merge Tracking), and that is also found in the SVN 1.4 documentation for The Key Concept Behind Merging. True, since Merge Tracking was introduced you typically only do "svn merge ^/project/trunk" into your working copy, but that's to move all changes from the trunk in - which you may not be ready for; and doing a cherry-picked merge is still 100% supported and encouraged when that is what you need to do.

One thing the SVN devs are keen on is giving the developer (or repository administrator) the flexibility to run the VCS as they need to meet the needs of the project(s) hosted in it. There's a lot about best practices, and you'll even find two conflicting best practices as each are targetted at conflicting methods of running a repository (e.g. trunk prestine vs trunk dirty).

You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.

I have done that without any issues, as I am sure many on the SVN mailing lists have as well - both before and after the Merge Tracking was added. It's a natural part of the work flow. I can think of no SVN rules that it violates. In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation (see the section Keeping a Branch in Sync Without Merge Tracking), and that is also found in the SVN 1.4 documentation for The Key Concept Behind Merging. True, since Merge Tracking was introduced you typically only do "svn merge ^/project/trunk" into your working copy, but that's to move all changes from the trunk in - which you may not be ready for; and doing a cherry-picked merge is still 100% supported and encouraged when that is what you need to do.

One thing the SVN devs are keen on is giving the developer (or repository administrator) the flexibility to run the VCS as they need to meet the needs of the project(s) hosted in it. There's a lot about best practices, and you'll even find two conflicting best practices as each are targetted at conflicting methods of running a repository (e.g. trunk prestine vs trunk dirty).

It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk.

This limitation has been lifted in 1.8. As long as you use no merge commands more complex than

svn merge ^/branch/to/merge/from

the merge works in either direction and should never flag spurious conflicts caused by changes being applied more than once.

There were ways to work around deleting a reintegrated branch in 1.7, by the way. But the new 1.8 merging works better. Just forget about --reintegrate, don't use any -r or -c options, and you can always merge in either direction without any need for deleting branches.

All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.

There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.

I'll bite. What's smug about svn? The developers make a version control system that they think is good, but they don't pretend it's The One True VCS. The users on forums, and Mercurial devs/users all likewise. By contrast Git fans, from Linus on down, act like it's the One True VCS and treat anyone who doesn't see the light as only worthy of contempt. I'm considering moving to Git or Mercurial, but I swear it'll be Mercurial just to get away from that friggin' attitude.

Documentation is also one of the strong points of SVN. The online book is fantastic.

If it's so bad, why is a feature of SVN called "Blame"?

You might want to check out O'Reilly's Beautiful Code. It has the same goal as TFA.

Available online:

• Chapter 2 about Subversion's delta editor, written by Karl Fogel.
• Chapter 24 about Software Transactional Memory, written by Simon Peyton Jones.

1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.

2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring, Plimus are free; Chargify, Subsify, Cheddar Getter, BrainTree, Spreedly charge; and Zuora is expensive.

3. Use Google Docs and Slideshare to share documents.

4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP

5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.

6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.

7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).

8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.

9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.

10. Development processes: Scrum, Extreme Programming. UML lets you communicate graphically about objects.

[1] http://hgbook.red-bean.com/read/how-did-we-get-here.html (look for the comment by Ben Collins-Sussman under the comparison of Mercurial and Subversion, where he acknowledges that SVN branching and merging is "complicated and buggy").

[Note: The summary's second link seems to be getting slashdotted, so I'm copying its contents to a comment here. The words are not my own.]

This entry was posted by Ben Collins-Sussman on Monday, 3 January, 2011

Author’s Note: These opinions are my own. I'm one of the original folks that started the Subversion project, but no longer work on it. These thoughts do not reflect the official position of either the Subversion project or the Apache Software Foundation, which are located here on the ASF blog.

Subversion has reached the realm of Mature software — it’s yesterday’s technology, not cool or hip to work on anymore. It moves slowly. It is developed almost entirely by engineers working for corporations that need it or sell support for it. Alpha-geeks consider software like this “dead”, but the fact is that something like half of all corporate programmers use Subversion as their SCM (depending on which surveys you read.) This is a huge userbase; it may not be sexy, but it’s entrenched and here for the long haul.

Subversion isn’t unique in this position. It sits alongside other mature software such as Apache HTTPD or the GCC toolchain, which are famous projects that are similarly developed by corporate interests. There’s a tricky line to walk: none of these corporations “own” these projects. They understand that they’re acting as part of a consortium. Each interest sends representatives to the open source project, contributes code, and allows their engineers to participate in the full consensus-based evolution of the software. IBM, Apple, Google, and numerous other companies have figured out how to do this correctly:

• 1. Let your engineers know what’s important to work on.
• 2. Let them participate individually in the community process as usual.
• 3. Profit. 98% of the time the corporations eventually get the features they want.

Today, however, we have a great counterexample of how not to participate in an open source project. Subversion was initially funded and developed by CollabNet; today at least two other companies — Elego and WANdisco — are employing numerous engineers to improve Subversion, and are just as vested in selling support and derivative products. CollabNet and Elego continue to function normally in the community, but WANdisco recently seems to have lost its marbles. Last week, they put out a press release and a CEO blogpost making some crazy statements.

It’s clear that the WANdisco CEO — David Richards — is frustrated at the slow pace at which Subversion is improving. But the two posts are simply making outrageous claims, either directly or via insinuation. David seems to believe that a cabal is preventing Subversion from advancing, and that “debate” is the evil instrument being used to block progress. He believes users are crying for the product to be improved, that the Subversion developers are ignoring them, and his company is now going to ride in on a white horse to save the project. By commanding engineers to Just Fix things, he’ll “protect the future”of Subversion, “overhauling” Subversion into a “radical new” product.

Is this guy for real? It sounds like someone read my friend Karl's book and created a farce of “everything you’re not supposed to do” when participating in corporate open source.

Even weirder, he’s accusing developers of trying game statistics by creating lots of

I respectfully suggest you read the second link in The Fine Summary. All Will Be Revealed (TM).

Their description of Subversion is almost blatantly wrong, and misses much of the improvements SVN brought about. It would have helped them to at least have read some of the Subversion Documentation - or even just the chapter on Subversion's Delta Editor in the book Beautiful Code.

Read the post you're replying to! That's all changed since 1.5. Now SVN knows when you branched and what you've already merged together.

Read about it here.

For most branching, the command would be a simple 'svn merge http://svn.example.com/repos/calc/trunk' from within the branch. The most complicated part is specifying the location of the branch to merge from (trunk in this case).

1.5 did wonders for SVN.

And, yes, me too: I wrote this in vi(1), which is why the article does not have all the fancy Unicode glyphs in the first place.

Excuse me - vim can handle utf-8 just fine. utf-8 file names and utf-8 content. on a vanilla slackware 13.1.
http://www.cl.cam.ac.uk/~mgk25/unicode.html#apps [cam.ac.uk]
# Vim (the popular clone of the classic vi editor) supports UTF-8 with wide characters and up to two combining characters starting from version 6.0.
# Emacs has quite good basic UTF-8 support starting from version 21.3. Emacs 23 changed the internal encoding to UTF-8.
And svn can handle utf-8 as well - http://svnbook.red-bean.com/en/1.4/svn.advanced.l10n.html [red-bean.com].

The repository stores all paths, filenames, and log messages in Unicode, encoded as UTF-8.

All it requires is ... set your locale and lang. "export LANG=en_DK.utf8" in "/etc/profile.d/lang.sh" (Slackware 13.1) and add some better fonts maybe.

I apologize for repeating myself. I've written the same thing further down already in reply to another user's post. But I just read tfa and felt the need to reply to the author of tfa.

the simplest programming tools for editing are straightfoward ASCII text editors: vi and (god help us) emacs. so by declaring that "Thou Shalt Use A Unicode Editor For This Language" you've just shot the chances of success of any such language stone dead: no self-respecting systems programmer is going to touch it.

Excuse me - vim can handle utf-8 just fine. utf-8 file names and utf-8 content. on a vanilla slackware 13.1.
http://www.cl.cam.ac.uk/~mgk25/unicode.html#apps
# Vim (the popular clone of the classic vi editor) supports UTF-8 with wide characters and up to two combining characters starting from version 6.0.
# Emacs has quite good basic UTF-8 support starting from version 21.3. Emacs 23 changed the internal encoding to UTF-8.
And svn can handle utf-8 as well - http://svnbook.red-bean.com/en/1.4/svn.advanced.l10n.html.

The repository stores all paths, filenames, and log messages in Unicode, encoded as UTF-8.

All it requires is ... set your locale and lang. "export LANG=en_DK.utf8" in "/etc/profile.d/lang.sh" (Slackware 13.1).

The Maltron -- http://www.maltron.com/. It's been a lifesaver -- not only a better shape (curved, to match your hands) but a better layout of letters (to avoid "single-finger hurdles" and other problematic movements). See also http://www.red-bean.com/kfogel/maltron.html.

Strangely, considering we're a Microsoft shop where MIS people choose Microsoft becuase it stops them having to make decisions or think (something they're not too good at anyway), we have a Drupal site for our user community.

http://drupal.org/

Its quite good, basically its another CMS, so pretty much everything sharepoint does, but less oriented on being a web-based network fileshare, without folders. Its used by a couple of high-profile websites, the Economist and the White House for example.

Apparently you can connect a Drupal site to Sharepoint "back end" using its CMIS module, and there are several file management modules in addition to the basic functionality. Collaboration doesn't even need to be discussed as its what the thing was designed to do :)

The site itself has fairly good documentation, and if you wantg really good example - check out Apache or Subversion, both very comprehensively documented.

Piracy is not meaningless. People are still using your product unlawfully.

So?

The way I see it, businesses don't make games because of a principle. They do so because you want to make money. And, annoying your customers with DRM might well make you less money.

I stick to one principle: If you make things available under conditions I like (no DRM) I will preferentailly buy it and recommend to other people. On the other hand, the more control the owner attempts to exercise, the more effort I will expend to avoid paying a cent for it.

Why don't you try hinging your livelihood on writing a book and then have people photocopy it instead of buying it? We'll see how you feel about piracy then.

Cory Doctorow seems to be doing fine. I bought a physical copy of the Mercurial book, though it's all right there, in the link. With source available. I also paid for the games linked above.

I work as a programmer and stand by my opinion.

Off the top of my hand, a Git feature for which I don't know a Mercurial equivalent -- git-cherry-pick. Want to rewrite history a bit? Create a new branch from sometime before the commits you want to change, then cherry-pick (point-and-click simple in gitk) the commits you want, in the order you want, ignoring the ones you don't. When you're ready, clobber master with your new branch.

hg transplant

I mean, quilt (hg mq) is cool and all, but how easy is it to rewrite history if you weren't in a quilt to begin with?

hg qimport has a '-r' option which allows you to "place existing revisions under mq control" (from hg help qimport)

Why Mercurial?

Why Switch to Bazaar?

I'll agree, although I don't have much experience with svn+ssh; it is easy to misconfigure it in a way that would allow data forging (or perhaps more aptly put, it's hard to configure it in a way that doesn't). This is in part why we went with mod_dav_svn as our SVN protocol. This does have the concern you voiced earlier about storing passwords in plain text on the client machine.

I haven't done it, but it's supposedly possible to configure DAV SVN to utilize client certificates for authentication (TLS auth among others). Your communications would be encrypted, and only people who have access to a user's personal certificate would be able to pretend to be that user. It's discussed at http://svnbook.red-bean.com/en/1.4/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn.sslcerts . Then your SVN server has a CA it trusts, as do your SVN clients. The client cert can even itself be password protected if you want so that even if the client cert gets intercepted it still can't be used without a password (this of course defeats saving your password so you don't have to retype it each time you do a svn operation).

This is about the highest order security and authentication available; it's all OpenSSL stuff. So it all depends on what level of security is appropriate.

I get your point about not being able to trust the repository if developers have unlimited access to it. That's not the case for us; only I and one other person have that kind of access to the repository, but he or I could do it. GPG signing tags is an interesting idea. What is the unique data that is signed (to protect against a replay)? I may borrow that idea and have our build system GPG sign an MD5 manifest when it creates the release tag. Even if someone had svnadmin access to be able to forge entries in the repository; they wouldn't have the build system's GPG key.

Authenticity of the code isn't as important to us as being able to prove ownership of the code, so although I respect that what you're describing is valuable to some people, I'm not sure how much benefit it brings us (but like I said, if I can cryptographically sign a hash manifest, might as well).

FWIW, thanks for the conversation, this has been enjoyable.

http://www.red-bean.com/fitz/google/where-are-my-socks.html

They already know.

Please check out such books as Mercurial: The Definitive Guide and Real World Haskell. They were freely available when being written and remain such, but in the same time both books were published as usual (on paper) by O'Reilly:

http://oreilly.com/catalog/9780596800673/
http://oreilly.com/catalog/9780596514983/

The source code used to create the books is also available. So you may use the same work flow.

O'Reilly publishes the Subversion book, and it's also available free online (and as a full PDF)

http://svnbook.red-bean.com/

This might be an interesting avenue.

For some statistical evidence (built on a very small sample size) that code review is worth it, see this section of a chapter from O'Reilly Media's book Beautiful Teams:

    http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#gumption-sink

That section is not about code review per se (it's about how a seemingly trivial interface decision affected code review), but it includes some code review stats from two projects, and discusses how frequently one project's code review catches mistake from previous changes.

(Disclaimer: I wrote the chapter, but it seems pertinent enough to this discussion to be worth posting.)

--Karl Fogel

Here you go: http://svn.red-bean.com/ale/repos/trunk/lisp/gene-menus.el

All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.

When was the last time you used SVN? Everything you just said is very confusing, 1.5 came out over a year ago and seems to have most of the features you say it does not.

http://subversion.tigris.org/svn_1.5_releasenotes.html
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.cherrypicking

As for rebasing, this is the first I've heard of it. It sounds interesting, but I don't really understand the problem it was meant to solve.
From http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase

Suppose you are a contributor to a large project, and you want to add a complicated feature, and to present it to the other developers in a way that makes it easy for them to read your changes, verify that they are correct, and understand why you made each change.

If you present all of your changes as a single patch (or commit), they may find that it is too much to digest all at once.

If you present them with the entire history of your work, complete with mistakes, corrections, and dead ends, they may be overwhelmed.

Just seems a little superficial to me :\ A single patch is too much, the actual VCS history is too much, so the ideal is offering a doctored up change history?
Wouldn't the end result be more interesting? I think good source comments with other documentation would be easier to understand and more proper than reviewing the change history of someone's patch.
Since when was how someone's patch was developed more important than what was developed? Isn't diving into the VCS to find reasons for something being just a sign that the code wasn't documented properly? So, yes, we dive into VCS history to solve preexisting documentation problems, but when it comes to accepting someone else's patch, isn't that the time to simply demand good comments and or documentation?

I like what I've heard of DVCS systems so far, but I don't see what the mad rush to git is all about. Maybe it just makes more sense in the OSS context where a bunch of strangers are working on a project, wherever, whenever they want to. *shrugs*

1A->B->C->E->F->H
1...\->D--^->G--^

Unfortunately, the problem with earlier SCM's is that in creating state H they try to merge both D and G into F. They forget that D was already merged into E, and try to merge it in again. This obviously causes problems; either conflicts; or even worse, mysterious code duplication or deletion.

To work around this, many coders made scripts that recorded the previous merge point through automated tags or other magic. Unfortunately, the diagram I showed above is a relatively simple case. The history graph can be much more complicated, and simple scripts will break.

Git solves all of this by knowing the topology of the ancestry diagram. It knows exactly what has been previously merged, and what hasn't. This means when multiple branches are merging between themselves it "just works".

With subversion, don't you merge a specific range of revisions, such as "C->G" in your example?
Also, while maybe not as nice as git's merging, isn't subversion 1.5's merge-tracking exactly what you're talking about? Now the range of revisions doesn't need to be specified, AFAIK.
source

I'd love to hear from anyone who has both git and svn experience. I't be interesting to know if there are any features that would benefit smallish teams, or if subversion has more or less been keeping up in that area.

One more "I only know git because when I was looking at code versioning systems it looked cooler than CVS" post is gonna make me throw up.

Agree 100% with the parent. You should be using version control. In fact, its such a common issue that there's even a term for what the original poster is asking about:

VENDOR BRANCHES

Go google that now. You can find more information for your system here...

* In (a) CVS book
* In the SVN book
* One method of doing this in bzr

With git or mercurial, patch queue solutions are probably what you want - stgit or the newer TopGit for git, Mercurial Queues for mercurial. You want to use patch queues so that you have a clean idea of how to get from their code to your code - managing vendor code via merging branches means your code history is littered with merge info making your patches less clear to your maintainers.

Agree 100% with the parent. You should be using version control. In fact, its such a common issue that there's even a term for what the original poster is asking about:

VENDOR BRANCHES

Go google that now. You can find more information for your system here...

* In (a) CVS book
* In the SVN book
* One method of doing this in bzr

With git or mercurial, patch queue solutions are probably what you want - stgit or the newer TopGit for git, Mercurial Queues for mercurial. You want to use patch queues so that you have a clean idea of how to get from their code to your code - managing vendor code via merging branches means your code history is littered with merge info making your patches less clear to your maintainers.

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

...God created DocBook and Subversion.

We use DocBook and SVN to author/edit/maintain the MySQL Manual and related documentation.

Most of us working on the MySQL docs team also use oXygenXML for editing - it's neither libre nor gratis, but it's not terribly expensive, and it works well on any platform with decent Java support (one of the few Java GUI apps I've seen that really works, and works well). Handles many common XML formats including DocBook, XHTML, DITA, and TEI. You can also supply your own DTDs/schemas for custom XML formats. Includes both code and visual editing views, as well as instant validation and a built-in Subversion client. Easy to produce HTML or PDF output from XML source. Also has some nice XQuery and XSLT tools if you need them.

Just "svn cp foo bar" makes a branch of "foo" called "bar". Is that so enormously complicated? I fail to see your point. :)

I guess I was thrown off by the Subversion book:

And now the easier method of creating a branch, which we should have told you about in the first place: svn copy is able to operate directly on two URLs.

$ svn copy http://svn.example.com/repos/calc/trunk \
                      http://svn.example.com/repos/calc/branches/my-calc-branch \
            -m "Creating a private branch of /calc/trunk."

Committed revision 341.

There's really no difference between these two methods. Both procedures create a new directory in revision 341, and the new directory is a copy of /calc/trunk. This is shown in Figure 4.3, âoeRepository with new copyâ. Notice that the second method, however, performs an immediate commit. [7] It's an easier procedure, because it doesn't require you to check out a large mirror of the repository.

At best this just seems really clunky.

Well, you shouldn't commit until you believe you have it in a state where the changes are usable (i.e. don't break the tree), but beyond that, I'd rather see more commits of smaller amounts of code than giant commits that change ten thousand things. If you end up having to back out a change, it's much easier if you can easily isolate that change to a single commit. My rule is commit early, commit often. I'm not the only one, either:

http://blog.red-bean.com/sussman/?p=96

If you publish a subversion repository over webdav, you can easily accomplish this with a feature known as AutoVersioning. As for using webdav to edit a 32MB file, I cannot vouch, but using this method is completely editor agnostic, assuming your OS has a method of mounting a WebDAV directory as a logical volume.

Subversion stores merge history? Where? If it does, why do the instructions tell you to manually track the merge revision numbers yourself? http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.1

This is the one thing that really annoys me about subversion - it is seriously missing some key bookkeeping here. Yes, I know there are scripts that hack it in, but that's not the same as doing it right in the first place.

You can do checkout-edit-checkin in SVN as well. That's what locks and svn:needs-lock property are for. See overview and details in official documentation.

You can do checkout-edit-checkin in SVN as well. That's what locks and svn:needs-lock property are for. See overview and details in official documentation.

Ah a fellow Article-reader. we must both be new here.

The thing that drives me nuts about this article is that I have been making this very argument for more than 10 years now, since my family tried to push me into CS school. The simple fact is that I was already writing in assembly in early high-school, and C shortly after that. As a manager and later, as a small-business owner, I've interviewed dozens of people with CS degrees who claimed they were programmers, only to find out quickly in an interview that they haven't the foggiest clue what a compiler does, or any relevant understanding of how a data structure manages to exist. Pointers? what are those? Why did you laugh when I said GOTO? Garbage collection? That's on Thursday.

I don't know that there will be no call for the type of programming CS programs teach today, in the future... in fact the way I see it, 70% of the apps that business runs on can be done in the "plumber at the store" style. Many of these require intimate understanding of the problem domain, which is one thing that CS used to be fairly lacking in prior to the "Java Shift". .

So does SSH. It's the server fingerprint. Much like a certificate, unless you have knowledge of what it should be prior to the connection, it's hard to know you're compromised. The problem is exacerbated by inexperienced users, but fundamentally it's the issue of trusting an unknown set of credentials.

What I'd like to see is a very simple source code control system, built on the same design. Perhaps one that would just serve the needs of a single programmer.

The SVN devs have known from the beginning that the lack of merge tracking constitutes, to use their verbiage, a "headache". For 5 long years, SVN's "Best Practices" solution was to track merges manually in the commit log messages. This "Best Practice" could be best described as, to use the technical terminology, "really fucking error-prone."

Look, I like SVN, I use SVN, I hope they get merge tracking (and 'svn obliterate', as long as I'm creating my Christmas List) ASAP. My only point here is that the great-grandparent's claim, that "It's trivial to branch and merge in SVN", is a heaping, stinking load of crap, to use the technical term. You know it, I know it, CollabNet knows it, everybody knows it.

I'm guessing that even sqlrob (173498) knows it.

You mean you're looking for a good book, so you can find the switch command.

You mean you're looking for a good book, so you can find the switch command.

Ignoring Linus' heinous unprofessional attitude, massive ego, and completely insulting comments, there's a lesson to be learned here: you and your team need to decide whether you want centralized or decentralized version control. There are advantages and disadvantages to both methodologies. Anybody who gets up on a stage and tells you that "all centralized systems are garbage, decentralized is the one true way" isn't giving you the full picture. (And likewise, anyone who says the opposite is equally off their rocker!) 80% of software development takes place within corporations, and there's a reason centralized SCM has worked so well in that environment. Decentralized systems might be great for certain open source communities, but it's not what most organizations want or need. If you'd like another viewpoint on why centralized might sometimes be better than decentralized (even in open source projects), take a look at this essay I wrote a while back.

I'm one of the original designers/developers of Subversion, and even we (in the svn developer community) are well aware of both sides of the coin. We're seriously considering adding decentralized features to svn 2.0. We've also added true merge-tracking magic to the imminent svn 1.5 release (so svn is no longer "hand waving" merges, they'll be just as simple as in decentralized systems.)

If you truly believe that distributed SCM is the the Only Way of working in all situations, then I suggest you try to push these systems on corporate teams, and see how they fare. Distributed systems have a model that's much more complex for the average joe-user to understand, and as a result most existing distributed systems have extremely complicated UI's. If they're complex enough to confuse open source nerds, think about the rest of the world's programmers...

Keep an open mind about this stuff. No matter what Linus says, there's no magic SCM bullet.

So don't do it.

The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.

It's always done late in a development cycle, in the rush to get the project out the door.

Why? It doesn't have to be. At least if you use something that isn't horribly broken.

So don't branch, and DON'T allow concurrent checkout of any code - FORCE the DEVELOPERS who need to work on the same code to COORDINATE their work EARLY in the development cycle. Of course they'll bitch.

Yes, they will. Because this is a monumentally stupid idea. Because the entire *purpose* of revision control systems (note: "CVS" stands for "Concurrent Versioning System") is to make it possible for developers to work on things at the same time. The idea is that you can get more benefit from the concurreny than you get difficulties from merging.

If your technical leadership has the spine to show prima donna twits who won't follow development rules the door. Of the entire company.

Rules like "merge early, merge often", perhaps? Fixes the problem, and *doesn't* cripple development horribly like your idea would.