Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Submission + - Subversion project migrates to Git (apache.org)

gitficionado writes: The Apache Subversion project has begun migrating its source code from the ASF Subversion repo to git. Last week, the Subversion PMC (project management committee) voted to to migrate, and the migration has already begun.

Although there was strong opposition to the move from the older and more conservative SVN devs, and reportedly a lot of grumbling and ranting when the vote was tallied, a member of the PMC (who asked to remain anonymous) told the author that "this [migration] will finally let us get rid of the current broken design to a decentralized source control model [and we'll get] merge and rename done right after all this time."

Comment Re:The Future Does Not Compute (Score 1) 140

+1 on "The Future Does Not Compute". One of my favorite books on this topic; IMHO it didn't get enough notice when it was new -- would be nice to see it get some now.

And Chris Daw, if you're out there: I still have your copy! I bought my own long ago; I've been trying to track you down ever since to return yours.

Comment Re:Both Have Their Purposes (Score 1) 378

Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.

Tree conflicts are inherent to any version control system, not just Subversion.

People complain about Subversion's tree conflict handling a lot. I believe this is because development work done so far was only about detection of tree conflicts, leaving many users helpless because tree conflicts can be complex and hard to understand and resolve.

The 1.8 release is taking some steps towards the eventual goal of helping users resolve any tree conflicts instead of merely detecting them. If you move a file or directory in Subversion 1.8, and need to update the working copy before committing the rename, and the update receives edits for the renamed file or directory, you'll now see a menu which allows you to apply the incoming changes to the renamed location:

Tree conflict on 'foo.txt'
> local file moved away, incoming file edit upon update
Select: (mc) apply update to move destination, (p) postpone,
(q) quit resolution, (h) help:

This only works for 'svn update', however. It doesn't work for 'svn merge', yet. That's planned for a future release.

Comment Re:But can SVN merge a branch yet? (Score 1) 378

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.

Comment Misleading summary (Score 5, Informative) 378

I'm a Subversion developer and would like to clarify this bit of the summary:

Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.

The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.

Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Working...