GIT is a distributed version control system – that means it doesn’t require to have any central repository. It’s possible to build system by exchanging commits between equal nodes. It’s convenient, however, to mark one repository as central one. Of course you can change your decision at any time. I’ll show you how to do that.
Coloured git output on console is a very helpful feature. It was enabled by default on git interface cogito. I liked it, but had to switch to raw git few years ago (cogito is deprecated now).
Fortunately current version of GIT supports that nice feature. It can be enabled with few settings in ~/.gitconfig file:
[diff] color = true [pager] color = true [status] color = true
Additionally pager used (less in my case) should support ANSI colors (~/.bash_profile):
export LESS="-R"
And now diffs are rendered using colors that improve readability (anyone who doesn’t review changesets before commit? 
). Now diffs look much better on a X terminal:
Let’s say you tracked someone broke HEAD of trunk and you want to reverse that single commit from main branch. Subversion makes very handy syntax for reverse merges:
svn merge -c -19203 https://REPO_URL
In example above you do reverse merge of 19203 revision (note “-” sign before revision number). After that merge:
In order to fix broken commit original author should do the opposite:
svn merge -c 19203 https://REPO_URL
(note there’s no “-” before revision number). Then:
You probably already know that Subversion stores some kind of metadata for all files added to repository. It’s called “properties” in Subversion vocabulary. This key-value map is responsible for registering ingored files masks, file attributes, internal file content type etc.
The property I’m going to present today is “mime-type“. It describes file content in similar way to HTTP header “Content-type” telling svn client how to handle the file. Typical values are: “text/plain”, “application/octet-stream”. Especially first part of mime-type is important:
If you do not set this properly right you may end up with messed binary file (end-of-line conversions) or non-mergable changes in text file (that is marked as binary by mistake).
Of course during adding a file to workspace one can forget to set those properties correctly. Here auto-props comes with help. Auto-props are applied when “svn add” command (from command line or from GUI) is issued. Configuration is placed inside “~/.subversion/config” file. Here’s my config fragment from one of projects.
[auto-props] *.csv = svn:mime-type=text/plain *.java = svn:mime-type=text/plain *.sql = svn:mime-type=text/plain *.sql = svn:keywords=Author Date Id Revision URL *.jar = svn:mime-type=application/octet-stream
Besides mime-type svn:keywords is being set in the example. It controls which keywords are expanded in source files.
What’s the purpose of internal project documentation? To help people do their jobs. Developers need the knowledge to be distributed across the team, testers need definition of proper system behaviour, marketing needs information on product features to sell it.
Important knowledge that may be required by developers doing updates may be summarized in few sentences:
There’s simple method of automatically saving and retrieving this kind of information: Subversion (or any other version control system). How?
Powered by WordPress