Link: “Μάνα blogger”

Από το blog του adamo, ένα link οδηγεί στο πολύ ενδιαφέρον post Μάνα blogger.

Δε χρειάζονται σχόλια από μένα. Το “www.digitalbox.gr” έχει γράψει με πολύ ωραίο, εύσχημο και σοβαρό τρόπο, με ακρίβεια και σαφήνεια, το 99.999% της άποψης που έχω κι εγώ για όλη τη “φασαρία περί blogs”.

Slashdot AC dismisses LOTR in half a sentence or so

Sometimes, AC comments in Slashdot are priceless:

http://slashdot.org/comments.pl?sid=456578&cid=22447110

A nice article about dVCS in the Enterprise

Bryan W Taylor posted a very intriguing writeup a bit earlier, titled:

`The Need for Distributed Version Control in the Enterprise‘

There are a few points of the article that seem a bit controversial. For instance, I am not sure I totally agree with the comments abouts “feature scoped” development.

On the other hand, I found the explanation about the advantages of distributed version control systems (dVCS) in the enterprise quite good. A few of the great aspects of the article are:

• There is an excellent description of how peer-to-peer development can boost productivity
• Some of the bad things about using the One True Central place for all commits are described, without falling for the temptation to bad mouth Subversion too much
• Merge tracking is described in passing, and some of the reasons why it is a Good Thing(TM) are listed
• Bryan also mentions some of the pains of working in a really parallel style of development, with multiple active branches at the same time
• A fairly objective description of what is good about Git and Mercurial is included; good points and potential shortcomings of both systems are listed

I really liked his post.

Thanks, Bryan

.scm subdirs

I just stumbled upon an interesting Subversion bug.

Issue 707 on the bug tracker of Subversion is now several years old. It seems to be related to one of my personal pet peeves with Subversion: the use of `.svn’ subdirectories everywhere.

When using CVS, the `CVS’ subdirectories which clutter a working area are merely annoying. When using Subversion, the `.svn’ subdirectories are, in my opinion, a bit over the edge of `annoying’. They are almost ’silly’.

I’ve always been annoyed by having to `fgrep -v CVS’ to iterate through all the files in a CVS workspace. Precisely the same level of annoyance kicked in when I started having to `fgrep -v .svn’. In fact, this annoyance and the lingering memories of it, are one of the reasons why I originally liked Perforce, Git and Mercurial. There are no `.p4′, `.git’ or `.hg’ subdirectories in every single directory of a workspace in those SCM systems.

It is quite intriguing that a misfeature of SCM systems that feels `pretty unhackish’, turns out to be a source of difficult to solve bugs too. I guess this is just another way of saying that after years of working with SCM software, one develops a certain `hacker instinct’ that values simplicity over gratuitous exceptions. This instinct kicks in every time one of these exceptions is noticed (like `CVS’ and `.svn’ filesystem clutter).

I hope that, eventually, simplicity will somehow win, and we will stop having to deal with either the filesystem noise of all the `CVS’ and `.svn’ subdirectories, or the bugs which result from the mere presence of this noise.

Merging should be *this* easy

Is merging so easy in your SCM system?

$ pwd
/home/keramida/hg/mercurial/gker
$ hg pull crew
pulling from /home/keramida/hg/mercurial/crew
searching for changes
adding changesets
adding manifests
adding file changes
added 54 changesets with 143 changes to 82 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg up -C keramida
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge
merging mercurial/commands.py
merging mercurial/hgweb/webcommands.py
merging tests/test-hgweb-commands.out
79 files updated, 3 files merged, 3 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ 

If you are using a VCS to keep track of a “vendor” source tree, plus your own local modifications, enhancements or features, and you repeatedly merge from “upstream” sources, then you deserve something like the merge shown above.

The “keramida” branch in the Mercurial “branch” we saw above is a personal branch which I use to keep my laptop’s installation in sync with the latest Mercurial “crew” repository.

The steps to pull a new upstream version and merge it into my own “branch” are summarized below:

$ cd ~/hg/mercurial/crew
$ hg pull
$ cd ~/hg/mercurial/gker

$ hg pull crew
$ hg update --clean keramida
$ hg merge

The last steps are, essentially, the “merge process”.

If you are still using an SCM that forces you to plan ahead for a week, then set aside an entire day’s work to “Perform The Merge(TM)”, maybe it is time to start looking at Mercurial:

http://www.selenic.com/mercurial/

In the meantime, I’m off to read a bit more of prof. Lessig’s “Code v2“, because tonight’s “merge” with the crew version of Mercurial is done, pushed to 10 different systems I often use, and installed already :-)

G. K.