knocte :: MonoTema

Subversion 1.5.0 has been recently released (June the 19th) and I'm surprised with the tons of great stuff it brings. Some highlights:

• A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.
  Consider this scenario: Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to 'foo', and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file 'bar', and unversion the file 'foo' (if it had no uncommitted changes, Subversion would remove it entirely.) From Sally's point of view, her changes seem to be lost; the newly added 'bar' file has the older content, and the file 'foo' has been taken out of version control.
  In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn't send a whole new file during the update, but rather instructions to copy something that likely already exists in the working copy. So Sally's 'foo' file is copied to 'bar' (with local edits intact!).
  
• Merge tracking means Subversion keeps track of what changes have been merged where. This reduces the overhead involved in maintaining branches, and gives users a way to inquire what changes are merged — or are available to be merged — on different lines of development.
  Example (one of the improvements in place): Merging changes from (say) trunk to a branch no longer requires that you specify the revision range. Instead, each time you want to sync up with trunk, you can just do:
  

  
     $ cd BRANCH_WORKING_COPY
     $ svn merge URL_TO_TRUNK
  

  
  Subversion will figure out what changes from URL_TO_TRUNK have not yet been merged and pull in just those changes. When it's time to merge the branch back to trunk, do this:
  

  
     $ cd TRUNK_WORKING_COPY
     $ svn merge --reintegrate URL_TO_BRANCH
  

  
  
• Sparse checkouts (via new --depth option): Many users have very large trees of which they only want to checkout certain parts. In previous versions of Subversion, checkout -N was not really up to this task. Subversion 1.5 introduces the --depth option to the checkout, and other subcommands.
  
• Conflict resolution is now done interactively by the command-line client for the update/switch/merge subcommands.
  
• Relative URLs and @peg revisions for svn:externals.

Don't you think this is AMAZING? This means we almost got full/real MOVE support and that merging is taking the best ideas from DVCS systems (yes, we lack yet local commits).

To get up to speed with DVCS features I would also add pending commits feature although there are concerns and people seem to prefer it to be implemented upstream in bug tracking tools.

Well, I guess you already may have noticed I don't like current DVCS tools (at least the most popular), by a different set of (a little bit subjective, I know) set of reasons:

- Git: it's implemented in an unmanaged language (yeah SVN too, but at least the latter is cross-platform!).
- Bazar & Mercurial: they're implemented in a "too-managed" language (yeah sorry I dislike dynamically typed languages very much, especially for big developments that need to have a long life; yeah, refactorings are a pain with these ones, although I don't know the test coverage they may have...).

Maybe Git# (Mono SoC2008) is the answer? (I don't know the progress of this project.)

I was discussing about this yesterday with JP, and when I talked to him about this SVN 1.5.0 he said "too late!". Ermmm, what?, Gnome hasn't switched to DVCS yet so, why too late? Maybe because it's imminent? I don't know. Sincerely, there is much contradiction about how people approach migrations... Today I've been attending for almost an hour a meeting about Gnome Mobile, and one thing that was arised is the lack of flexibility and ease of use of the Gtk+ toolkit, as opposed to other toolkits. People were concerned about it and wanted to fix it, and nobody wanted to give up pushing Gtk+ just because it's old. Then, why doing this for Subversion? Subversion is very mature, and their devs have demonstrated to be worried about its lack of flexibility wrt the new distributed ways of work, so they are fixing it, they are *supporting* us. And however at Guadec here it seems everybody wants to push for the migration (but only taking care of doing the correct decision, i.e., select the 1 from the 3 we all know, but why not considering just to update to new SVN and wait a bit more to see where we go?

Well, now that I'm talking about Subversion, I'm going to talk you about a couple of features I worked on recently (and committed today), as my first ITO day, in the Subversion Addin of MonoDevelop: revert to revision, and revert changes from a revision. The mandatory screenshot (you get to this dialog when requesting the Log inside the Version Control contextual menu):


This reduces the need of having a console open when coding with the MonoDevelop IDE, which is a thing that many developers request.

Another feature I completed is the new pattern for searching in many files inside MonoDevelop: Current project (previously we only had "Whole solution", "Directories" and "Open files"):


Enjoy them! (Currently on SVN.)

Labels: CSharp, General, Mono, Programacion, SoftwareLibre