Xlinks and branch per task in a DVCS environment.

Xlinks and branch per task in a DVCS environment.

Wednesday, June 20, 2012 Pablo Santos distributed 0 Comments

I’m going to tell how we use the Xlinks down here at the Plastic SCM dev team combined with replication.

No surprises if I tell you we use Plastic SCM to handle the plastic development :)

Yes, you know, eating our own’s dog food and all that.

Well, if you take a look at our items view you’ll see something like the following:

This screenshot is coming from my laptop, and I have a server (using SQLite backend) installed on it, and then I push/pull changes from the central.

We’ve 5 main directories and each of them is pointing to a different repository.

01nerva is our main code repository, located at a repo named “codice”. The server code, gui code, plugins, everything is in there. I’ve a light replica with only a few branches and changesets instead of the whole repo on the central server at the office.

02nervathirdparty is our “third party” directory. Libraries coming from external sources, database providers, tools (like nant, ant and many more) live there. It is stored on a different repo, called “nervathirdparty” which is also on my laptop. We use a writable xlink so when we branch on the “codice” repo, if there are changes on this directory, a branch is automatically created and tracked.

03pnunit is the test code. A full repo with “pnunit tests” (PNUnit stands for Parallel NUnit and it is a library we developed years ago and we contributed to the NUnit project. It allows us to coordinate tests among different machines). We use a writable Xlink to this repository, because it is extremely common that a modification on the “codice” repo goes with some code to test it (GUI tests, PNUnit tests and so on).

Documentation is a directory pointing to the “doc” repo, which is where the main docs live (test results, schedules, analysis docs, designs and many more). We use a readonly Xlink because we normally use a different workspace to deal with design docs. In fact we only have this one here for testing purposes.

Taskdocumentation, again another Xlink. This is a very interesting repo: each time we complete a task, we add screenshots and a short explanation so that the tech writers can use it to document the new stuff. Yes, we could have used an issue tracker for this, a sharepoint server or whatever… but when you develop a SCM… everything looks like a repo :P

Pulling branches

Ok, now, as I said I work replicated without direct conn to the central server. So, considering a single task I need to pull can have like 3 associated branches on 3 different repositories… how do I manage to make the replication process simple?

Look, I have a sync view defined with all the sources (on localhost) and destinations (on Diana). So I update everything, then filter by the branch I want to pull (or push), multiselect on the different repos, and click on “pull branch”.

And hence I can get all the branches I’m interested on with a single click (or push them!).

Was it helpful?

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.