Well after redoing my home network I needed to reinstall a VM with a TFS server for source control.  I thought it would be fairly straight forward as I had done it in the past.  This time I thought I would use newer technologies (SQL 2008 vs 2005, Windows 2008 versus 2003).  Boy was that a mistake.  After numerous attempts to get a functioning TFS server I finally have it (3 days later).

Below is a list of failed attempts.

1.  Windows 2008 and SQL 2008.  Way too much custom installation and setup for source control.  Microsoft has to be out of their minds when setting this up.  I have done many custom installations (MS and Linux) and have to say this latest TFS attempt was the worst ever!!!! I would prefer to setup a Solaris Box and attempt multiple versions of Oracle on the same box before doing this again.

2.  Windows 2003 and SQL 2005 – I went with Win 2003 so it would install Windows Sharepoint Services for me (one less step).  Something happened with permission’s on one of my user accounts to my reporting services installation.  Too bad it didn’t catch it in the beginning.  After I few hours of trying to recover from a FAILED installation of TFS I scrapped the VM and went back to a snapshot.

3.  I get everything up and running (I thought) and then the next day get a strange SQL error I can’t pinpoint.  It has to do with the WSS_Configuration database.  After a couple of hours or more of searching I decided a clean operating system was in order.  Only about 15 minutes into the new operating system did I discover that while I applied the Service Pack for Visual Studio – it did not include the Service Pack for TFS.  This caused file version errors which were the root cause of my error.

4.  So now I am writing this post while waiting for the last of my service packs to be applied to TFS.  Here’s hoping I can create a new project from a remote pc.

Tips for install TFS 2008 on a single server

1. Use Windows 2003 (32bit)
2. Use SQL 2005 SP3
3. Print out the directions and follow the prerequisites exactly
4. If running a VM – take a snapshot after every major software installation
5. Do not skip steps
6. Read the directions
7. Read the directions again
8. PAY CLOSE ATTENTION TO EVERY STEP IN THE PREREQ section!!!
9. If the TFS installation fails – go to a backup  / snapshot – do not waste your time.  The installation SUCKS and does NOT recover gracefully.

Tips:  MICROSOFT – please try to make TFS 2010 a little more straight forward for installation.

In the big IT shops source control is rather common place. However in smaller shops or for individual developers a version control system may not be a top priority. A source control system may seem overly complicated and unnecessary. Fortunately they’re not as cumbersome as you might think and the benefits are well worth the small effort. 

So what exactly do we mean when we talk about source control, or version control systems? Basically a source control system provides a central place to store your code and a mechanism to track revisions of that code.

Source Control

One common reason people start using a source control system is when more than one developer needs to access the code. There used to be a time when our live production system served as the central repository for accessing code. Jim had a task to update a webpage so, he would connect directly to the server and make a change to the file in the live environment. Bob may have a change to make and then go do the same thing. What about quality, what if there was a mistake or a file was accidentally deleted. To avoid this Developers may keep code in another location other than the live site. For individual developers this is typically on their computer. For multiple developers, this central spot may be a shared network drive. With that risk averted what else could go wrong?

What if Jim had a lot of changes to implement. Some core functionality needed to be changed and it couldn’t be done at one time. Typically Jim would grab a copy and keep it locally until it was finished then post it. Here’s the rub, after Jim takes the copy but before he puts it back, Bob goes on the server and makes a change. Later Jim posts his changes and overwrites Bob’s code. Geez thanks Jim.

Here’s where we start to see features of a source control system come in. In this case if they were using source control, when Jim tries to put his changes in, the system would alert him that other changes had been made since he pulled his copy.

Source Versioning

So what about this versioning concept, why do I care? Have you ever used undo on your computer? You know you make a mistake, hit ctrl+z and revert back to what you had before? Here’s a question, how do you revert back to something you had yesterday or last week. If you had something versioning your files you could do just that.

Say you’re doing a website and are making some wording updates to a promotion. You post the changes and a few weeks later your client tells you there’s a law suit over that change. Apparently a customer claimed the original promotion said one thing but the company say it was something else. How do you go back and see what really was on the site? Version control.

Another scenario, you have a functional application that your client is using in production. Now you have another customer who wants to use it too. You decide to update the application to accommodate more than one client. After a few weeks of tinkering you still can’t get things the way you want. It’s functional and in your central repository but not quite right. Your client comes back and wants a change to the app in production tomorrow. Your repository copy has the new changes in it, if you make the change now it will have your unfinished changes in it. With a version control system you can pull a snapshot of the code from before you started your changes and update it without affecting your in progress changes.

Getting started using a source version control system

There are a variety of free and fee based solutions. Some of the big names like ClearCase and Preforce sometimes show up in the big companies but the free solutions like CVS and SVN are more popular. CVS has been around for ages and had a huge following. SVN, also known as Subversion, started as an effort to fix some of the challenges that were in CVS. These days SVN is very widely used and is pretty much the standard.

Lets take a look at SVN. Most systems have a server component and a client component. The server piece is where your code is stored and the client is an interface for you to access that code. SVN is no different. You can go out and grab the server components then go get a client too. You don’t need to do this at this point though. For this example and for simple setups, the Subversion client TortoiseSVN has everything you need. So go ahead, down load and install it.

Once installed create a directory to act as your central repository. In this case I’ll create one at c:\repo. Navigate into that directory and right click. In the context menu choose TortoiseSVN -> Create repository here. Just like that you have a functional source control system.

Lets start using our new system. Before we do I need to clarify one thing. We just created a setup that mimics a server configuration. While this example is setup locally, it could ba on a server somewhere. The next step explains how you access that content and keep a useable copy locally.

We’re ready now to use our SVN instance. Find a place on your computer where you’ll be doing your work, maybe c:\workspace. Navigate into that directory and right click. In the context menu choose SVN Chekout. This will pop up a window asking you where your repository is and how you want to get the contents. 

For the URL type in file:/// followed by the path to where you create the SVN repository earlier. This is not the working directory, rather the location of the repository. Since we installed this locally it will be something like file:///C:/repo but if this were on a server it could be http://someserver.com/repo

In this scenario we’re starting with the repository and pull the contents into our workspace. If you already had files in a workspace you could start there and push them into the repository with the import option on the context menu.

Using Your New Source Control System

Now that we have things setup lets try it out. Create a text file in your workspace called MyFile.txt. Add some content in it. Save and close. Depending on your version and setup the icon may differ but you’ll see a marker on your file like a question mark. This is telling you that this file is not in the repository or under source control. Since it is a new file we need to get it in there. Right click on a white space and choose

svn commit. The following popup will show you all files   that have been updated locally and are not in sync with the repository. you should notice that our file is listed, but is not checked. Since this is a new file we need to select it and have the SVN client add it to our repository. Make sure our file is checked and hit ok.  The confirmation screen will show that everything has been added and updated.

Now go back and make a change to that file again, Save it and take a look at the new icon. 

This exclamation point tells us that this file, which is under version control, is out of sync with the repository. Again right click and commit changes.

Now all is good and we get a Green checkmark.

So there you have it. The barebones basics of getting going with a source control system.

In future posts we’ll be using source control systems in our examples which will give you more context how this fits into a development process. Even with this basic setup you’ll be able to point your IDE to this local repository and follow along. Don’t just use it for our examples though, you can keep versions of any file this way. Version your wedding list, or Photoshop files. Whatever it is, revision control systems provide a lot of value.

For now happy versioning. 

Git is a tool used extensively for open source projects.  It is a way of distributing source control instead of the typical central repository.  History has it that Linus Torvalds himself developed the original tool.

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

Why is it called git?  The theory is that Linus named it after himself.  However, no one seems to know for sure.

Why git?  It all started as a dispute between the Linux developers and BitKeeper.  The BitKeeper tools had been free to the community until the company charged the developers with reverse engineering their product.   The result was that developers would need to pay to continue using BitKeeper.  Given the “free” nature of Linux development this obviously did not go down well.  Linus led the project to develop an alternative and the result is git.

The overall good news is that git has been widely adopted even though it was only created starting in 2005.  There are several good features it has compared to the traditional source control solutions.

• Offline changes
• Free (always helps)
• Fairly simple commands
• Distributed source management
• Open source (for the hardcore)

To get a better introduction, visit the git homepage.  As a set of examples of this homepage:

There is also a section on quick start.  Git has two paths for creating a repository.  Either it is created from a clone from another server or it is created from scratch.

Anything in parentheses is meant to be replaced with specific actions (like a directory or file).  To keep it simple, it is best to experiment with a locally created depot.  It is worth doing an easy walk through of the creation.

1. git init
2. git add .
3. git commit -m “My message”

“git init” creates the initial depot for this current project.  It creates a subdirectory (usually hidden) called .git which contains all the information that git needs to keep to manage the source.  Think of it as being where everything is kept to keep git happy.

“git add .” instructs git to find every single file under the current directory and add it to the staging area to be prepared for committing. It will only add files that are new or changed when used with the “.” which is a great trick.  If there are files that you do not want to automatically add, you can always change the “.gitignore” file to skip over them.  Typically the object and binaries need to be skipped if the tree is actually built.  Doing the add is really just a sign of intent.  It does not actually change anything in the git tree.  Also of note, if you change any files that have been added, you need to add them again if you want to capture the changes in the staging area.

There is nothing to fear with commitment.  Commit with “git commit” just means that you want to capture all the changes into one thing.  This is where it updates the local git tree and it is seen as a kind of “snapshot” of where the code is at.  Keep in mind that a commit means nothing to anyone else.  A commit is just a local thing.  This enables git to be used offline and without the need for a central server ever.

However, git can also be used in a distributed team.  In fact, that was the original intent.  That is the point of the other path for creating a depot on the local machine.

Working off of a remote depot is in this order:

1. clone a remote depot (git clone)
2. make changes to the local files (git add)
3. commit the changes (git commit)
4. send the patch to someone that cares (git format-patch)

This is not the only way to do it.  It is also possible to submit the changes back to the remote depot assuming you have been authorized.

Coming from a world of PVCS and Perforce, git can take some getting used to.  It seems uncommon for git to be used in commercial products in Citrix (except for Xen products).  XenApp and XenDesktop are based on Perforce.

There are so many different places you can go to find out more about git.  Here are some examples:

• Gitcasts – collection of videos about git features
• Pro Git – online book about git
• Git from the bottom up – understanding the internals
• Official git documentation site

Linus Torvalds (git creator) speaks about git at Google Talks.

Thanks goes to Michael Wookey in Citrix Labs Sydney for being such a great git advocate.

Version Control Systems(VCS) only covers a portion of Application Life cycle Management(ALM).  Its important to understand what your needs are and use the correct tools.  VCS will fall short if your looking to manage application life cycles.  If you are building enterprise solutions and run with large teams, making the investment in ALM pays off almost immediately.

Modern software projects tend to be very complex and require fast and efficient delivery cycles, that leave simple VCS systems lacking.  Even in small teams, ALM has many advantages.  I find very few cases where simply having a source control system is sufficient.

In the world of ALM, there are two approaches.  You can cobble together an ALM system from many tools or you can get an integrated solution.  I always prefer the later, because the cost of doing the tools integration is high.  In addition, it tends to create pockets of knowledge of the process workings and in some cases a single point of failure among the skill sets.  You can get integrated solutions from vendors like Borland, Microsoft or Serena.

There are cost differentials to consider.  Many of the ALM products or commercial and come with a price.  While you can probably get VCS, Defect, Project tracking tools to create an ALM process, you still pay for that in time and complexity.  A home built solution takes time to get off the ground and usually has that one guy that knows how it all works.  To everyone else it tends to be a mystery.

If your producing software, the quality can be directly impacted by the process that is applied to the production of the software.  Using an ALM tool can greatly amplify a software engineering teams ability to create a quality product.

Some of the benefits of ALM:

• Better collaboration and communication among teams
• Increased productivity and faster development through tool integration
• Improved quality and defect tracking
• Adaptability to business changes and market demand
• Improved project governance through visibility and transparency

Managing the life cycles around code are fundamental to leveraging your teams most effectively.  Everything that interacts with that code, from new requirements to maintenance support and defect corrections, can cause the code base to experience entropy.  There are already very complex process and problems and chaining effects of change that need to be mitigated.  Using tools that allow developers, testers and project managers to have visibility into the process and make adjustments quickly help to keep the product in a stable and manageable state.

As projects grow, the importance branching, merging and conflict resolution become extremely important.  And the ability to map artifacts to code and trace it through the process becomes vital to releasing features while maintaining existing features.  Planning and scheduling work against branches and communication with quality teams can be cumbersome when your process and tools are not integrated.

How you organize your teams and the tools they use can make or break the product you are trying to produce.  Simply using a VCS will limit your ability to be competitive in the marketplace.  He who has the best people and the best process wins.

Ignorance is Bliss

This has got me angrified!  There are no simple steps on how to install an SVN server onto a windows server.  All the steps assume that you already have Apache installed.  I understand that you can run SVN as a stand-alone installation but I want to run it in conjunction with Apache and take advantage of single sign-in provided by integration with active directory.

I suddenly find myself eating my own words.  After writing my tirade, I went back and found a couple complete svn packages. The one that I opted for is called Visual SVN (www.visualsvn.com).  They have both a free and a pay version.  Being cheap, and generally against the principle of paying for open-source software, I opted for the free version.

My installation experience went something like this…

1. download the msi package
2. double-click and follow the steps to create repository and users
3. run tortoise svn to access the newly created repository

It couldn’t have been simpler or more elegant even if Apple had created the product!  It may make the UNIX crowd angry as they seem to have created a product that does away with the arcanity of command line arguments, but these guys did an excellent job of bringing svn into the windows age.

En el intento de integrar un poco mas los servicios de la red interna de la empresa, cambiamos de Seguridad de Texto Plano a Seguridad Integrada con Windows Authentication (SSPI).

Cual es la idea de esto? simplemente mantener un unico password por usuario para cualquier servicio que segurizado (lo que se conoce como single-sign-on).

El cambio es realmente sencillo de realizar. Lo unico que necesitamos es tener un Dominio de Windows que realice la autenticacion y el modulo SSPI de Apache (http://sourceforge.net/projects/mod-auth-sspi/).

Porque un modulo de Apache? porque SVN no maneja la seguridad de los directorios, sino que la misma esta a cargo del Servidor HTTP, que en este caso es Apache.

Ok, el paso a paso…

1. Bajar el Modulo SSPI de Apache (http://sourceforge.net/projects/mod-auth-sspi/)
2. Bajar el servicio Apache en el Servidor donde se encuentra SVN.
3. Copiar el archivo “mod_auth_sspi.so” que se encuentra dentro del archivo que bajamos en el paso 1), al directorio “\httpd\modules” dentro del directorio donde se instalo SVN, o dentro del directorio donde se encuentra instalado Apache.
4. Ahora necesitamos cambiar la configuracion de Apache. Para esto vamos al directorio “\conf” dentro del directorio donde se encuentra instalado Apache y editamos el archivo “httpd.conf”
   1. Agregar linea “LoadModule sspi_auth_module modules/mod_auth_sspi.so” luego de la ultima linea que comienze con “LoadModule”. Esto cargara el modulo SSPI en el proceso de Apache.
   2. Cambiar la configuracion de Location. A continuacion muestro como quedo mi configuracion:
      
<Location /svn>
      DAV svn
      SVNParentPath C:\path_del_repositorio
      AuthType SSPI
      SSPIAuth On
      SSPIAuthoritative On
      SSPIDomain TUDOMINIO
      SSPIOfferBasic On
      AuthName “Mi Mensaje de Autorizacion”
      AuthzSVNAccessFile C:\path_del_archivo_de_accesos
      Require valid-user
      </Location>
   3. Es necesario eliminar o comentar (con # al inicio de la linea) la configuracion anterior de “AuthUserFile”, ya que ahora la autenticación se realiza  a través del dominio.
5. Por ultimo sera necesario modificar el archivo de acceso o autorización. Este es el archivo del que se hace referencia en el key “AuthzSVNAccessFile” en la configuracion que modificamos anteriormente. En este archivo es necesario agregarle a todos los usuarios el Dominio al que pertenecen. Ej: Guido por Dominio\Guido.
6. Iniciamos nuevamente el servicio Apache y si todo esta bien, iniciara normalmente.

Ya tenemos nuestro repositorio con seguridad integrada!

Obviamente sera necesario que el usuario Dominio\Guido exista en el dominio de windows, o cambiar al usuario Guido por el usuario de Dominio que utiliza esa persona.

Si el servicio Apache no inicia, es posible ver los errores de inicio del servicio en el EventViewer de Windows.

One of my colleagues at work had gotten hard disk booting failure. Luckily, the HDD was attached to other PC and readable. The issue was that there were CCRC views with checked out files. The files couldn’t be checked in or undone unless the views were properly recovered. However, when all the CCRC and CCRC views  were copied over to newly built PC, the views were not visible in CCRC. CCRC doesn’t recognize the local CCRC views folders even though everything was copied to the exact same location as before.

The key to resolving this issue is to find out where the view information is stored locally on PC. Not in Windows registry. Not in the CCRC program folder. It is in the ‘.ccase_wvreg‘ file in user home folder. Once you find and open it in a text editor, you will get pretty good idea.

For more detail on .ccase_wvreg file, see About the CCRC .ccase_wvreg file.

As far as my experience is concerned, CCRC (ClearCase Remote Client) is not that stable on Windows (It was much more stable on Linux).
One of the problems I faced was the “undo checkout” failure with the “Unable to find checked out version” error. I guess it happened because of some network issue when I tried undo initially. Again, my guess is that undoing was done on server side but it was not reflected properly on my CCRC client.
This ghost checked-out file is a real problem because you can not update or check in anymore. Luckily, I could find a solution myself.

The solution that I found involves manual editing of “.copyarea.db” file in the directory where that checked-out file is. So do it at your own judgment and risk. Here is the procedure:

1. Make “.copyarea.db” file writable and open it using a text edit of your choice.
2. Find the line with the problematic file name and modify the number in the end of the line from ‘1′ to ‘0′.
3. Save modified “.copyarea.db” file and change back it to ‘read-only’.
4. Open CCRC and find that the file is not marked as ‘checked-out’ anymore. (It may be marked as ‘hijacked’ already. Then skip next step)
5. Do “update resource” on the file. And find that file turns into ‘hijacked’ state.
6. Do “undo hijack”. Once it is done with no problem, the file state is synched and good to go.

I’m in the process of (hopefully) switching SVN hosting provider from eurosvn.com to xp-dev.com. To make that happen I first have to create a dump of my existing repository and it’s not something you can do on an online repo, svnadmin dump only works on local paths (which is a good thing .

2. Make a dump

I’m in the process of (hopefully) switching SVN hosting provider from eurosvn.com to xp-dev.com. To make that happen I first have to create a dump of my existing repository and it’s not something you can do on an online repo, svnadmin dump only works on local paths (which is a good thing .

I’m going to post here the details of making a local readonly mirror repository. It’s useful for, at least, two reasons:

1. Make a backup
2. Make a dump

Ready? Ok, let’s start opening your command prompt:

1. Create a local repository

svnadmin create [YOUR NEW REPO PATH]
eg: svnadmin create c:\svnrepo\iacoware.

The root path must exists (c:\svnrepo). By default the repository is created as read-only

2. Enable writing on your new repo

Open file [PHYSICAL LOCAL REPO PATH\conf\svnserve.conf] and decomment line

[password-db = passwd] (line 20 in my file)

This tell to SVN which file stores user’s credentials.

3. Add a new user

Open file [PHYSICAL LOCAL REPO PATH\conf\passwd] and add a new user under the [users] group (mine svnsync_user = svnsync).

4. Give your new user read/write permissions

Open file [PHYSICAL LOCAL REPO PATH\conf\authz] and add:

[/]
svnsync_user = rw

5. Enable rev propchange (revision property change)

Look for the file “pre-revprop-change.tmpl” in [PHYSICAL LOCAL REPO PATH\hooks]. Make a copy and rename it to pre-revprop-change.bat. Open it and remove everything, be sure to leave only:

exit 0

6. Initialize the repository

svnsync init [LOCAL REPO PATH using file:// protocol] [REMOTE LOCAL PATH] --sync-username [USERNAME] --sync-password [PASSWORD]
eg: svnsync init file:///c:/svnrepo/iacoware http://your.svn.hosting.provider/your.repository --sync-username user_svnsync --sync-password svnsync

Getting the local repo path right could be tricky. Pay close attention to the number of slash. I used the file protocol but you can also use the svnserve protocol:

eg: svnsync init svn://iacoware ...
(obviously svnserve must be up and running, eg: svnserve -d -r c:\svnrepo)

7. Synchronize

svnsync sync [LOCAL REPO PATH]. Be aware, if your repo is big, it could take a loooot of time.
eg: svnsync sync file:///c:/svnrepo/iacoware
From now on if you want to synchronize your local repository you have to repeat only step no.7

HTH

Troubleshooting

If the synchronization process goes wrong (it happened to me) next time you’ll try to sync you’ll receive an error “failed to get lock on destination repos, currently held by…”. Run this command:

svn propdel svn:sync-lock --revprop -r 0 [LOCAL REPO PATH]

and life will be happy again

References

http://journal.paul.querna.org/articles/2006/09/14/using-svnsync/

Just moved to Git on Windows. It gives me more flexibility for the local repositories and distributed development for my new team.

Found the following series very helpful for the beginners (my engineers never used Git before):

Git For Windows Developers – Git Series – Part 1

Git For Windows Developers – Git Series – Part 2

Git For Windows Developers – Git Series – Part 3

Take a look at Tortoise Git as well. Reduces all the command-line noise drastically:

Continuing the series of blog posts to help you move away from subversion.

In Subversion, you can ignore files or whole sub folders with Subversion properties. Unfortunately, you have to do this everytime you add a new project to your source code structure – for example, you have to add Subversion properties to ignore the new obj and bin folders.

With Bazaar you can also ignore a specific file or directory. e.g. to ignore a directory:

bzr ignore src/myproj/bin

The first time you ignore a file, a .bzrignore file is created. This file contains all the files and folders you want BZR to ignore. You can push this file to a shared repository and then everyone who makes a branch from the shared repository will ignore the same files.

Rather than ignoring files and folders individually, you can update this file yourself to add pattern matching file paths you want ignored. Paste the following into your .bzrignore to ignore all bin folders, obj folders, ReSharper folders and associated files, and Dev Studio files that you normally do not put in source control:

**/bin
**/bin/**
**/*.user
**/obj
**/obj/**
**/*.sln.cache
**/*.suo
**/aspnet_client
**/*_ReSharper*.*
**/*.resharper

Now, when you commit .bzrignore and push this file back to the shared repository, everyone who pulls the changes to their branches will ignore the same files.

To always ignore these files for all of your BZR branches, you can paste the above code the global ‘ignore’ file. You can find this at:

1. Windows Vista: C:\Users\your-user-name\AppData\Roaming\bazaar\2.0\ignore
2. Windows XP/2003: C:\Documents and Settings\your-user-name\ApplicationData\bazaar\2.0\ignore

I’ve had enough of Subversion and decided to move to Bazaar. Click BZR in the Tag Clould to see my series of blog posts to help you do the same.

Do any of these Subversion complaints sound familiar?

• You are randomly instructed that “you need to run update”. You then do an update – which takes ages to complete. And then, finally, you see that there were no changes that needed to be downloaded.
• You are randomly instructed that “you need to run cleanup”.
• You have huge merge problems. For example, you use ReSharper to rename a class, and some else has updated that class in the meantime. You then see the dreaded tree conflict error (shudder). Or even worse, you rename an entire namespace and folder (double shudder). Now you really are in for a world of pain.
• Your merges tend to be more and more manual. You frequently have to use WinMerge because Subversion hasn’t got a clue.
• You are often waiting around for Tortoise to update/check for modifications/anything.

I have a subversion repository on my USB pen drive. I get tree conflicts and merge problems with that, and I’m the only user!

The main problem is merging. Our team has to work on branches as we have different projects running concurrently, working on the same code base. We don’t know which project will be going live first, or even if the project will be released at all (they may get canned). So, we need an efficient merging process.

Merging has become so problematic that we’ve considering adding merging as a separate task for each MMF we implement – that’s how long it takes nowadays. We’ve even considered putting a “Work In Process” limit on particular pieces of code to make sure two unrelated MMFs don’t touch the same code.

[Can you tell that I am not happy with Subversion?]

So, I decided to try something else.

I was going to try Git. I downloaded binaries, documentation and guides. But then I read this article: Renaming is the killer app of distributed version control. And I agree, renaming is really, really important. We rename files all the time. We refactor.

Git doesn’t handle renames as a “first class operation” – renames are just a delete operation followed by an add operation. This is the same as Subversion. I assume Git handles it much better than Subversion, but I wanted a SCM that has it built in.

So, I decided to start using Bazaar: renames are a first class operation in Bazaar, and it also has “Intelligent Merging” to cope with your Dev Studio file moves or renames.

For a full feature list of a number of SCM systems see this source control comparison page.

So far, I’m happy:

• It runs natively in windows (I didn’t really want to run a unix-type shell to get Git working).
• It is easy to work with from the command line (I thought I’d miss Dev Studio integration, e.g. VisualSVN and Ankh, but I don’t).
• I even decided not to install TortoiseBZR – you don’t need it. [Tortoise is one of the reasons I wanted to move away from Subversion so I didn't want to install the BZR equivalent.]
• BZR comes with some GUI applets if you really need your GUIs. For example, there is a useful one for viewing change logs (command: “bzr qlog”)

To make the move, check out getting started with Bazaar source control.

Quick pointer to a particular TortoiseSVN feature I wasn’t familiar with for some reason. This enables reverting to a previous revision easily.

The easiest way to revert the changes from a single revision, or from a range of revisions, is to use the revision log dialog. This is also the method to use of you want to discard recent changes and make an earlier revision the new HEAD.

via Roll back (Undo) revisions in the repository.

Ultimamente tenho socorrido várias pessoas que vieram me fazer essa pergunta, ainda que para quem já está familiarizado com a ferramenta isso não seja um problema.

“Eu fiz o shelve lá conforme você recomendou só que agora não sei como recuperar as modificações do servidor! E agora, já era? As perdi? Como faz?”

Muita calma nessa hora. A solução é bem simples, porém, o problema é compreensível. O botão “Unshelve” está em localizações pouco intuitivas na IDE do Visual Studio 2008. Vamos à elas:

1 – Em “Pending Changes”: De um certo modo, concordo que um changeset é composto de modificações pendentes de check-in, mas não são todos que pensam da mesma forma. Para grande maioria, “Pending Changes” são check-outs locais pendentes de commit para versionamento. Concordo, afinal Shelveset é um conjunto de modificações armazenadas no Servidor, mas ainda não versionadas.

Mas voltando ao que interessa, o “Unshelve” está aqui: View -> Other Windows -> Pending Changes.

2 – Ao clicar com o botão direito em qualquer item no solution explorer. Sim, ali mesmo. Mas desde que você tenha algum projeto aberto. Não vale aquela “Solution1″

Localização do botão "Unshelve Pending Changes" ao clicar com o botão direito em qualquer item do Solution Explorer.

Ah, aproveitando! Galera, vamos dar mais atenção à essa feature do VSTS. Esse tal de Shelve pode ser muito últil para você!

Um abraço,

I’m reading The Pragmatic Programmer at the moment, and one thing they recommend is to always use source control, even for small prototypes and personal projects.  Now I’ve been using source control at work ever since I started coding, but I’ve never given serious thought to using it at home – I only have a single machine for a start.

But that’s not really an issue these days, as there are a number of Internet hosts that can act as your source control server – and this gives the additional advantage of being able to access your code wherever you can get on the ‘net.  And as well as being a good way of backing things up,  you also get a full revision history, which can be handy when things go pear-shaped!

Now, I don’t want to spend any actual money on this, but that’s not a problem as there are many open source options available – I didn’t look too hard here as I’ve already used Subversion (SVN) at a previous job and it has a big following, and is supported by most of the online hosts.  Same with the client, which is the part I had to install on my machine – TortoiseSVN integrates with Windows Explorer, is free, easy to use, and has all the functionality you’d expect.

TortoiseSVN in action

So the main thing to do was chose a host.  Again, there are many free options – this site has an excellent comparison of the available options, including several free ones.  One of the main things you need to decide is whether you want your code to be open source or not, as several of them only host open source projects.  I’m happy enough with that, so after a little research online I went for Google Code, which has a lot of space, unlimited users, and some useful features.  Two minutes to create a Google account, then you can crate a new project by entering a few basic details, and you’re ready to rock & roll!

Creating a new project in Google Code

Once you’ve got TortoiseSVN installed and your Google Code project set up, you just need to upload your project – this blog has some useful tips that will get you up and running in a couple of minutes.  And that’s it!  In less than 10 minutes you can be up and running with a full source control solution, including online administration:

Google Code administration page

And if you want to get someone fixing your defects for you, all they need is an SVN client and you’ve got yourself a development team.  If I’d known it was that easy, I’d have done it years ago..

In an effort to dust of my long languishing programming skills I’ve decided to learn Cocoa programming on the Mac. Sure, my job uses Java primarily but I mostly understand it, even if I don’t regularly code Java. Ultimately I’d like to contribute to an open source project, Adium for example. Contributing to a widely used open source project would be acceptance on a grand scale.

The Adium project uses Mercurial for source control, and I’ve already started learning it. What I really need is an update XCode / Cocoa tutorial or book. I’ve got a copy of Vermont Recipes, but it was written for the inital XCode release and too many of the underlying tools have dramatically changed for it to be an effective resource. Fortunately my employer has a Safari account and I can access several Cocoa programming resources there.

In addition to learning Mercurial and XCode / Cocoa, I’ll need to reintroduce myself to programming. It’s a discipline I’ve always enjoyed but one I’ve lost. The concepts are still here, I just need to brush them off and reapply them.

Ideally I’ll track my progress here. Hopefully this posting won’t be the only one on this subject.

There are times when you have a requirement of only selecting “Custom Page layouts” when a user wants to create a new page in Sharepoint Portal site.

I won’t go in details of how to adding and deploying new custom page layouts using feature,  but you can refer here for it :

http://blogs.msdn.com/syedi/archive/2008/08/01/custom-site-definition-for-collaboration-portal-template-sharepoint-2007-wow-moss.aspx
http://spreflections.wordpress.com/2008/09/24/deploy-master-page-and-page-layout-as-a-feature/

Once you have a added a custom page layout, you don’t want the user to pick from any sharepoint built-in page layouts.

To achieve that functionality you can mark those layout types to be hidden on the feature activation code. As all the page layouts are item in a list which is source controlled via sharepoint you will need to check out the file and then only update the “Hidden Page” attribute.

here is how you can ahcieve it.


using (SPWeb web = site.OpenWeb())
{
web.AllowUnsafeUpdates = true;
SPList list = web.Lists["Master Page Gallery"];
foreach (SPListItem item in list.Items)
{
//Note that if your page layout's content type needs to be different
if (item["Associated Content Type"] != null && (item["Associated Content Type"].ToString().IndexOf("Article Page") != -1
|| item["Associated Content Type"].ToString().IndexOf("Welcome") != -1))
{
item.File.CheckOut();
item["Hidden Page"] = "True";
item.Update();
item.File.CheckIn("");
}
}
list.Update();
web.Update();
}


now when the feature is activated, user will only be able to see custom page layouts.

Good luck!

As described in this previous post, I was on my way to glory setting up my own source control.

This post is about setting up github.

The account creation is straight forward though one is also required to give the ssh key (not necessary) . Ample details on the site on how to generate on if you dont have already.

So my folly was of a typo. Somehow I typed git@github instead of git@github.com while adding remote source repo. After that when I tried to push the code I got the following error

ssh: github: Name or service not known
fatal: The remote end hung up unexpectedly

After a couple of permutation combinations i zeroed down on the cause. Now the simple thing was to remove the origin. Which is easy

git remote rm origin

Thats it. Good to go. Now one can specify another remote origin and continue as happy users.

First, when I started to research if “cvs” would work on my FreeNAS I found a whole lot of links to cvsd… but I recall using cvs over ssh for many many projects. Couldn’t I run just cvs over ssh?

Yes You Can!!! And this makes cvs on FreeNAS easier than ever. Not much modification is required, and I am very happy to report that I’ve got mine working very well.

So let’s get into it shall we?

In order to get cvs working, we need the cvs binary. FreeNAS is a FreeBSD core underneath the covers. There are many many releases of FreeBSD so we should find out what release we have. We can do this by running uname on the command prompt of your FreeNAS.

Mine says:

nas:/mnt/default# uname -a

FreeBSD nas.ejes.gotdns.org 6.4-RELEASE-p3 FreeBSD 6.4-RELEASE-p3 #0: Sat Apr 18 22:17:59 UTC 2009     root@vmbsd64i386:/usr/obj/freenas/usr/src/sys/FREENAS-i386  i386
nas:/mnt/default#

Now that I have the release number, I can simply browse the FreeBSD repository at ftp://ftp.freebsd.org (the 6.4 release is ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.4-RELEASE/6.4-RELEASE/packages/All/), and following the directory tree you can find most any other release.

Simply download the “cvs” binary cvs+ipv6-1.11.17_1.tbz (ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.4-RELEASE/6.4-RELEASE/packages/All/cvs+ipv6-1.11.17_1.tbz)

I used fetch on my system:

nas:/mnt/default# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.4-RELEASE/6.4-RELEASE/packages/All/cvs+ipv6-1.11.17_1.tbz cvs+ipv6-1.11.17_1.tbz
                        100% of  442 kB  266 kBps

Then, in the GUI, I added a group called “cvs”, I gave it the group id 2401 because port 2401 was the cvs server port (and I may want to use pserver one day).

The Group I used for my cvs

the user _cvs for myself

Thankfully a tbz file means a tar bzipped file. So we can use tar to extract the package from freeBSD i want all my cvs stuff in one place so i’m going to extract it to my /mnt/default/cvs/tmp directory.

nas:/mnt/default/cvs/tmp# tar -vxzf cvs+ipv6-1.11.17_1.tbz
x +CONTENTS
x +COMMENT
x +DESC
x +MTREE_DIRS
x man/man1/cvs.1.gz
x man/man5/cvs.5.gz
x man/man8/cvsbug.8.gz
x bin/cvs
x bin/cvsbug
x bin/rcs2log
x share/cvs/contrib/README
x share/cvs/contrib/check_cvs
x share/cvs/contrib/clmerge
x share/cvs/contrib/cln_hist
x share/cvs/contrib/commit_prep
x share/cvs/contrib/cvs2vendor
x share/cvs/contrib/cvs_acls
x share/cvs/contrib/cvscheck
x share/cvs/contrib/cvscheck.man
x share/cvs/contrib/debug_check_log
x share/cvs/contrib/intro.doc
x share/cvs/contrib/log
x share/cvs/contrib/log_accum
x share/cvs/contrib/mfpipe
x share/cvs/contrib/pvcs2rcs
x share/cvs/contrib/rcs-to-cvs
x share/cvs/contrib/rcs2log
x share/cvs/contrib/rcslock
x share/cvs/contrib/sccs2rcs
x info/cvs.info
x info/cvs.info-1
x info/cvs.info-10
x info/cvs.info-2
x info/cvs.info-3
x info/cvs.info-4
x info/cvs.info-5
x info/cvs.info-6
x info/cvs.info-7
x info/cvs.info-8
x info/cvs.info-9
x info/cvsclient.info
x info/cvsclient.info-1
x info/cvsclient.info-2
x info/cvsclient.info-3
nas:/mnt/default/cvs/tmp#

Go back and “Give full shell access to user.” to the _cvs user and log-in or “su _cvs” to become him.

Now we have to initialize the cvs root directory; mine is /mnt/default/cvs/root. Run cvs init, and we’re off.

nas:/mnt/default/cvs/tmp# su _cvs
%cvs -d ~/root init
%exit
nas:/mnt/default# chown -R _cvs:cvs cvs
nas:/mnt/default#

Everything should be functional, all we need to do now is add anyone we want to be able to access cvs, to the “cvs” group. I added “user” as a test.

On my OpenBSD terminal I setup a simple cvs system

$ CVS_RSH=ssh cvs -d:ext:_cvs@nas:/mnt/default/cvs/root checkout .

works! GREAT!! Add my user to the “cvs” group, remove “shell” access from _cvs done!

My Remote users have to set these settings:

CVS_RSH=ssh

CVSROOT=:ext:user@host:/mnt/default/cvs/root

CVSEDITOR=nano

Now I can import directories using: cvs import -m “comment” module_name committer start

Check them out on another machine using: cvs checkout module_name

Add files or directories: cvs add “file/directory”

And Commit my changes once they’re made: cvs commit

For example:

nas:/mnt/default# ssh user@192.168.0.2
user@192.168.0.2's password:
Last login: Tue Aug  4 16:46:50 2009 from 192.168.0.3
OpenBSD 4.4 (GENERIC) #1021: Tue Aug 12 17:16:55 MDT 2008
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
$ CVS_RSH=ssh; export CVS_RSH
$ CVSROOT=:ext:user@192.168.0.3:/mnt/default/cvs/root; export CVSROOT
$ CVSEDITOR=nano;export CVSEDITOR=nano
$ mkdir src
$ cd src
$ mkdir testing
$ cd testing
$ touch a file
$ ls
a    file
$ cvs import -m "testing" test ejes start
user@192.168.0.3's password:
N test/a
N test/file
No conflicts created by this import
$ mkdir new
$ cvs add n
$ touch new/more
$ cd ..
$ ls
testing
$ rm -rf testing/
$ cvs checkout test
user@192.168.0.3's password:
cvs checkout: Updating test
U test/a
U test/file
$ cd test
$ mkdir new
$ touch new/more
$ cvs add new
user@192.168.0.3's password:
? new/more
Directory /mnt/default/cvs/root/test/new added to the repository
$ cvs add new/more
user@192.168.0.3's password:
cvs add: scheduling file `new/more' for addition
cvs add: use 'cvs commit' to add this file permanently
$ cvs commit
cvs commit: Examining .
cvs commit: Examining new
user@192.168.0.3's password:
RCS file: /mnt/default/cvs/root/test/new/more,v
done
Checking in new/more;
/mnt/default/cvs/root/test/new/more,v  <--  more
initial revision: 1.1
done
$

What are some of the hurdles we have encountered with Cloud Development? What mechanisms have we used to overcome them? The problems posed by the different cloud platforms are different. I will be writing on this topic in a series blog posts. I expect to blog on these topics. If you know of others, please let me know. These list items will get hyperlinked over time.

1. Cloud Development for Google App Engine
2. Cloud Development for Amazon EC2
3. Managing software delivery from outsourcers
4. Managing evolution of database configurations
5. Performance and Stress Testing
6. Security Testing

In this introductory post, I want to cover activities that cross all platforms. The premise of Cloud Development is that the company does not own any hardware. Under these circumstances, how does software development get done?

Tight control over source code is essential. This need does not go away with Cloud Computing. It becomes more important! It used to be that if you lost track of the latest source, you could always look at the working machine. No longer, not consistently anyway. In the Google App Engine support forum, there is a predictable weekly request from someone or the other for Google to help them retrieve their latest source code. The answer is always the same (no, can’t be done).  The team needs to use the source repository frequently to build from.  The source repository should be backed up, versioned and secure. What should be under source control? Everything! That includes source code (duh!), install scripts (Rightscale scripts, for example, for creating an environment), security settings,  even database configurations. This last item will require further discussion; more on it in a subsequent post.

The issue tracking database is the team’s second most important asset, after source code. It too needs to be backed up, versioned and secure^†.

Stupid Question #1: What actually constitutes a conflict?

Is a conflict when two people have changed a file, or is it when two people have changed the same part of a file and VSTS needs assistance to resolve it? Every other (sane) version control system in the world interprets a conflict as the latter.

Stupid Question #2: How is it “Auto Merge” when I have to tell VSTS to merge?

Stupid Question #3: If VSTS could not-quite-auto-but-with-the-press-of-a-button merge, and it managed to resolve everything all by itself, why on earth does it pester me about non-existent conflicts all the time?!?!?

Perhaps these questions are stupid, but I most respectfully submit that the answers are stupider.