Search This Blog

Tuesday, March 13, 2012

I wanted to replace column content '{ApplicationVersion}' with '{RegularMessage}' string. Postgres syntax seemed a little bit strange to me (because of the XMLPARSE) so I’m writing the solution here. As it turned I had to cast my content argument to text first as it was an XML-typed column - there is no automatic casting. If you forget to that the error pops up which suggests there is no replace function referenced but it actually means that there is no replace function with such arguments so you should cast your arguments:

Thursday, March 1, 2012

When working with a distributed repository system one needs to remember that it is slightly different from SVN and CVS repositories. I will put most aspects in points for easy remembering.

Your LOCAL commit time/order is remembered when pushing your changes. So if you commit changes on master and then try pulling and pushing it will create a nasty “divide and merge” track on master. It looks like this:

To prevent this behavior always do REBASE instead of pull when syncing with the distributed repository.

Rebase in TortoiseGit is available from rightClick->Git sync->Fetch&Rebase

If possible work on your LOCAL branch. For example, when your main branch is called “master”, create a branch called “localMaster” and commit changes to this branch. When the time comes to push your changes you will switch to “master”, pull the changes. Then switch back to “localMaster”, rebase localMaster in position to master to include all the changes which have been made on master and resolve any conflicts. Then switch to “master”, merge master from “localMaster” to include changes from “localMaster” in “master”. In the end you just push your “master” branch.

GIT good practices – using “master” and “localMaster” branches.

You clone the repository from source. And create your “localMaster” branch. So you have: “origin/master”, “origin/HEAD”, “master” and “localMaster”.

commit changes to “localMaster” branch

Switch back to “master” branch and pull changes from repo

switch to “localMaster” and do a rebase with “master”. In this way all the changes which have been pulled to master will be reflected in “localMaster” branch

this is how it looks “as a pure concept” after the rebase. You need to resolve any conflicts that can occur during this process.

switch to “master” branch and merge changes from “localMaster” to reflect commits made in “localMaster” to “master” branch

now that you have merged “master” and “localMaster” you can switch to “master” andpush your changes so that others can see your commits.