SVN

[Jonathan]

Does someone want explain to me how subversion works? I am familiar with CVS and Bitkeeper, so just the list of differences from one or the other would suffice.

I am really trying to figure out if I can make commits to my local version without messing up the Austin teams central repo.

[quantus]

Try this article - http://osdir.com/Article203.phtml

I got that link from the Articles and Reviews section here - http://subversion.tigris.org/links.html

It sounds like you're working with branches and merges so this webinar may also be useful - http://www.collab.net/webinar/21/

collab.net is a great resource for SVN in general.

[Jonathan]

Houle have specified: no branches.

[quantus]

Without a branch, I don't think you can "commit" to your local copy. Did you mean something else? Really, it's not that different from CVS from a workflow standpoint. It makes the revision management cleaner since commits are atomic, revision number is for the entire repository no matter if you update 1 or 9999999 files and it gives directories revision info as well.

[Jonathan]

Bleh, I was afraid of that.

[quantus]

I think Houle is keeping you from using one of SVN's advantages...

Cheap Branching and Merging

Because Subversion uses a database to store the repository, it can perform "lazy copies" of files very quickly. Subversion uses lazy copies for branches and tags; you simply copy your trunk to a new location in the tree, with Subversion tracking the common history. Very little space is used up on the server, and the operation happens almost instantly. Since CVS stores history in versioned files, making a branch requires that all the files in the repository are accessed and updated. In Subversion, a tag is simply a branch that is read-only and never updated.

By using its lazy copy system, Subversion makes merging changes very fast. It can track changes to all branches using a simple database query and generate precise merge information very quickly.

What are you used to doing with CVS or Bitkeeper?

[Jonathan]

Jonathan clones the central BK repo.
Jonathan adds Melting Clocks to the code. He checks it in to his local clone, but doesn't push the changes to the central repo.
Jonathan breaks Melting Clocks because he's trying to make them melt 200% faster.
Joe realizes he has a cool hack he can write for Melting Clocks to make Melting Faces. He pulls Jonathan's Melting Clocks into Joe's local clone, without the code going through the central repo or getting the broken code, only the checked in, working code.
Jonathan realizes the clocks will never melt 200% faster and reverts back to his old version.
Jonathan has another idea for speeding up the clocks by 150%. He breaks his code again.
Joe implements Melting Faces. Joe pushes Melting Faces to Jonathan's local clone.
Jonathan finally gets the clocks melting 150% faster. Now he has a clone with Melting Faces and Melting Clocks that melt really fast. He checks it in to his local clone.
Boss asks Jonathan where the hell all the melting is. Jonathan pushes Melting X code into the central repository.

Even more powerful when you realize this is a multi-tiered hierarchy, with the top level tiers in Oregon and Israel, another set in two different Oregon buildings, and then dynamic clusters as new features are worked on in my group.

git can do the same thing.

[Jonathan]

Specifically, I have a SVN source tree from Texas that I need to share with Oregon folks but am not ready to send back to Texas.

[quantus]

clones sound like branches... pushing to the central repo sounds like merging... I only see the "no branches" directive as the problem here.

Either that, or just take the entire code base, check it into BK, go on your merry way of cloning and such. Then deal with update and commit hell later when you pull all the changes you want to commit back to Texas into your SVN checkout.

On another note, this is my 3000th post! Woo, go me!

[Jonathan]

Except

A. branches are a PITA, clones/pulling is a single command line (bk clone/bk pull)
B. local clones/pulls/merges happen without upstream ever being informed. Israel's BK repo could go down for the next two months and Oregon wouldn't be affected, because they're fundamentally independent. Indeed, in this model there is no central model; they push code over here, we push code over there, and we each regard our central repo as THE central repo.

Believe me, I am seriously considering junking SVN and just importing everything into BK.

You have truly earned your new title, btw.

[George]

I use SVN at home and work. I'd say it matches or beats CVS across the board but loses to Clearcase for any but the smallest projects. Like CVS, the expected workflow is single repository. There is some support for cloning repositories, but it's not as integral as something like Mercurial (or gits, if I understand correctly).

Unlike CVS, there is essentially a single rooted file hierarchy which happens to have an extra dimension for version. Tags and branches are essentially just hard-links within the hierarchy, which leads to both good and bad properties. Branching (and it's special case cousin tagging) is trivial and fast. Merging is a pain in the ass because before version 1.5, it didn't track you merge history, making it easy to miss commits or double merge stuff. I haven't tried using 1.5 merging yet, but I understand it's only foundational and still isn't nearly as friendly as Clearcase's.

Tools are essentially identical to CVS. Command line has equivalents for all the CVS commands. On Windows, you ignore the command line, just like CVS, and use Tortoise. There are fewer tools providing integration with SVN because the checkout model is different enough from CVS and SCCS. SCons can't integrate with it, eclipse can.

[quantus]

For completeness, here's a Git for SVN user tutorial that provides a nice side-by-side comparison... After reading it, I kinda like the idea of local branches to track even more fine-grained incremental changes which can be pushed as a complete set later. It's kinda provides an extended undo function with tracking points wherever you choose them to be rather than every so many minutes like a dumb autosave would do.

Really, if there are no branches allowed, the dude is pushing for continuous integration and must tolerate things breaking all the time with automated tests to help detect and isolate those breakages.

[quantus]

Ok, I've been thinking more about how git works (and I assume BK works almost exactly the same). How in the world do you keep track of what is and is not in whatever repository becomes the final one used for a design? Since it is distributed and there is no central place where it must be kept, it's harder to link revisions with the issues they address in the issue tracking database. This makes it hard to link to revisions with issues, which in turn makes it hard to track "development done" status. Is there a link between test cases and issues in your projects? I guess you can skip "development done" tracking if you're tracking "verification done". Really, it'd be nice to have both to help detect modules that had particular trouble and should be more carefully peer reviewed as an extra measure to insure quality.

[Jonathan]

You are having a brain fart because you are conflating a people issue with a technology issue. You designate one repository as the release repo: Linus's, for instance. Stuff doesn't really exist in the project until it is in the release repo and tested properly.

[Jonathan]

Note that I'm pretty sure that no one I work with uses BK branches, by the way. It makes more sense just to burn disk space and have different clones, especially when you need to have them built simultaneously.

The Linux kernel is a great example of how distributed source control works. Linus has maybe 7 folks he trusts enough to merge their changesets. Each of those folks takes patches from another small ring of trusted folks. Andrew and a peer can work for six months on a new scheduler without the code ever touching Linus's repo, getting changesets from all kinds of wild and woolly hackers. At the end, when they feel they've nailed it, they poke Linus and he merges in their changesets. Now substitute two different corporate teams instead of Linux hackers and you see the way it goes.

To elaborate on the above central repo question, our release methodology has a new repo for every day which has all the commits which have passed the first level regressions. So at any given time there's probably three dozen "official" repos stretching over the past month, and any one of them can be cloned, revised, and the changeset pushed to the head (normally after pulling and merging from head). The final one that is totally validated is the one that ships.

[quantus]

First off, I can't burn disk space here which is really irritating. I never expected this strict of quotas. 10 years ago, sure, maybe. Today, never.

I gotcha, so the way to do it is to watch the release repo. What you're doing by watching 30 candidates seems a bit different and seems a bit less controlled since you're not necessarily sure which is the release repo? Until you're sure, the issue tracking software can't really link to a single repository and grab the revision history, but it would let you link it up later after release.

[Jonathan]

There's a symlink to the latest and the repos are named by date ww30a, for example. Works fine for issue tracking database.

[quantus]

http://wiki.open.collab.net/wiki/Subver ... e5c0b2b95e

Does Subversion have Changesets?

The question is a bit loaded, because everyone seems to have a slightly different definition of "changeset", or a least a slightly different expectation of what it means for a version control system to have "changeset features".

For the purposes of this discussion, here's a simple definition of changeset: it's a collection of changes with a unique name. The changes might include textual edits to file contents, modifications to tree structure, or tweaks to metadata. In more common speak, a changeset is just a patch with a name you can refer to.

Subversion manages versioned trees as first order objects (the repository is an array of trees), and the changesets are things that are derived (by comparing adjacent trees.) Systems like Arch or Bitkeeper are built the other way around: they're designed to manage changesets as first order objects (the repository is a bag of patches), and trees are derived by composing sets of patches together.

Neither philosophy is better in absolute terms: the debate goes back at least 30 years. The two designs are better or worse for different types of software development. We're not going to discuss that here. Instead, here's an explanation of what you can do with Subversion.

In Subversion, a global revision number 'N' names a tree in the repository: it's the way the repository looked after the Nth commit. It's also the name of an implicit changeset: if you compare tree N with tree N-1, you can derive the exact patch that was committed.

For this reason, it's easy to think of "revision N" as not just a tree, but a changeset as well. If you use an issue tracker to manage bugs, you can use the revision numbers to refer to particular patches that fix bugs -- for example, "this issue was fixed by revision 9238." Somebody can then run 'svn log -r9238' to read about the exact changeset which fixed the bug, and run 'svn diff -r9237:9238' to see the patch itself. And svn's merge command also uses revision numbers. You can merge specific changesets from one branch to another by naming them in the merge arguments: 'svn merge -r9237:9238 branchURL' would merge changeset #9238 into your working copy.

This is nowhere near as complicated as a system built around changesets as primary objects, but it's still a vast convenience over CVS.

Just some more fodder...

From this, it seems like you can do pretty much the same thing as git with svn, just rather than managing the repository locally, you're using a branch on the server instead. You basically create a branch, do your work. When you're done, create another branch from whatever the latest head of the main branch is. Merge your changes from the first branch into that to check that you're not conflicting with anything new. Then commit to the main branch when you're done. Fin.

Candidate releases are then just special branches or you can even just any commit onto the main branch which you can then automate testing for with something cruise control.

Now, with branches and tags, it should be possible to mimic change set functionality in SOS. Still, I wish that SOS maintain atomicity of commits to minimize ctrl-c getting the repository into a messed up state

[quantus]

Salvation for Jonathan...

http://www.kernel.org/pub/software/scm/ ... t-svn.html

git-svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.

git-svn can track a single Subversion branch simply by using a URL to the branch, follow branches laid out in the Subversion recommended method (trunk, branches, tags directories) with the --stdlayout option, or follow branches in any layout with the -T/-t/-b options (see options to init below, and also the clone command).

Once tracking a Subversion branch (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command.

[quantus]

Linus on git