Descriptor

Today Subversion 1.7 has been published! There are new features that are really interesting. Especially new Working copy format. If You know git You will be happy with only one .svn folder that new Subversion uses! There are some speed improvements, partly thanks to HTTPv2 protocol. For git fans there is even --git switch for svn diff command :) svn diff --git New Subversion should be also better with merges. For full description see release notes: http://subversion.apache.org/docs/release-notes/1.7.html New version can be downloaded from Apache Subversion site:  http://subversion.apache.org/download/#recommended-release

Idea is not new, similar approach can be found in many places but now it has nice name. Lately I read Node Web Development and Node.js modules in npm used this approach to make npm so awesome. Read more at website:  http://semver.org/ In a brief: There is API, it can be code or whatever but this is treated like API. Use 3 numbers: 1.2.3 - <major>.<minor>.<patch> Patch - bugifex - API comatible Minor - new or compatible API changes Major - any incompatible API changes How this can help? By using "strict" convention this can be used by tools (like npm) to make it easier to You to update dependencies. If You use library in version 1.2.0, then You can update easily it up to 2.0.0! Of course it is better co confirm it by developer that this really works, but if library developer uses semver like You, it should! There are many other rules, if You can't use it, at leas show it to You's co-workers, it would be great to really standardiz...

I was unable to put my Git repository to new SVN one, so for the future first create dummy svn repo, then clone it using git svn and work on this :)

Interesting question:  http://stackoverflow.com/questions/2064321/subversion-cant-merge-after-a-move But try this in real work: several feature branches, many bugfix branches and release branch. Add to it that not everybody in a team is svn master and You would know how svn "real" move is important. But this issue is 9 years old and even now is moved to future 1.8 release. Subversion 1.7 in roadmap is sheduled for Q1 2011. I am curious when it will be :)  http://subversion.apache.org/roadmap.html About month ago there was much more yellow dots so hope it will be soon. Tip: In 1.7 SVN will work a bit more like git: one ".svn" folder and even -git option for svn diff.

Great post about using git to work in team, to develope new new features, fix bugs and support production. This is great post and in most parts can be used in SVN, Mercurial or Bazaar. http://nvie.com/posts/a-successful-git-branching-model/

Znalezione w otchłaniach internetu: SVN - XX. Meeting of Warsaw .NET UG from Warsaw .NET User Group on Vimeo .

This is must read for all who uses TortoiseSVN. Daily Usage Guide This is really short and pragmatic guide. Strongly recommended!

Interesting post about SVN and .svn directories. At the beginning there is also a couple of links how to start with SVN. http://pythonconquerstheuniverse.wordpress.com/2011/03/16/learning-subversion-the-mystery-of-svn-2/

Flickr I've read about DevOps   a wikipedia and one aspect of it is not clear for me. How in Flickr they use Subversion? At this presentation:  http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr page: 38 - Always ship trunk page: 40 - Example of "branching in code" And there is Trunk for development, release branch to support etc. But how it looks like in Flickr? There is at page 38 "Always ship trunk" so developers must work on branches most of the time? Or first commit is with 'branching if's" in code? Personally I doesn't like a if's for branching idea... Chrome Recently I read about similar approach in Google Chrome Release Cycle  in which workflow are embedded   configuration options to do branching in code. 1: Everyone works on trunk, then they create stable branch and work on dev and to stabilize branch and ship all scheduled functions. 2: They work on trunk, has 3 channels, trunk, beta a...