What's coming? New Visual Studio AddIn

Another day... another plugin.

We're working on a new functionality which has been around since we first started working on our 2.0 release (looong ago on June 2007 or so): integrating the full GUI inside Visual Studio.

And now, we're almost there. I went to the first demo yesterday and I asked Daniel to send me some screenshots to post here.

What I find more interesting (ok, I love the CLI, but anyway, it's still interesting :-P) is that now a developer will be able to do ALL the operations inside Visual Studio and still benefit from all the Platic GUI functionality.

We'll try to find out whether it can also be integrated with Visual Studio Express Edition so that the Students out there can also use it!







Hope you like it!

Configure SQL Server database backend

Plastic can be configured to use different database backends to store data and metadata. This article will explain how to configure a SQL Server backend.

By default Plastic works with a Firebird embedded database but it can be changed to work with other databases like SQL Server.

Supported SQL Server versions
Plastic supports SQL Server 2005 or higher, basically due to new transaction isolation leves introduced with 2005.

Plastic can be configured to work with both SQL Server and SQL Server Express editions, but remember the latter has some size constraints.

For instance, you can use SQL Server Express edition in your laptop (remember Plastic supports distributed development and replication) to work with Plastic while you're disconnected if you prefer it better than Firebird.

Reasons to switch to SQL Server
There's not a rule of thumb here. My answer will always be: it depends on you!

I mean, if your company or your sysadmin is more used to SQL Server, then go to SQL Server. Some companies prefer to use a single corporate SQL Server and integrate all their data there, and this is perfectly possible with Plastic.

You can use standard SQL Server tools to query the databases, run back ups and so on.

Maybe you and your team are more used to set up and back up SQL Server than Firebird or MySql, and then you prefer to have your data there.

Plastic performance with SQL Server is very good too, something to keep in mind when your team grows or if you think you need Plastic to go faster.

Using a dedicated SQL Server machine for the database and another server for Plastic will increase performance under heavy load scenarios.

As you know upon installation Plastic comes with a embedded Firebird database set up, which is pretty good for a number of users but we recommend teams to switch to Firebird Server, SQL Server or MySql as the team grows.

Configuring Plastic server to work with SQL Server
Plastic database backend configuration is set up on a file named db.conf, located in the server directory (where the plasticd server is installed). It is a pretty simple xml file which tells the database backend to use and how to connect to it.

If you've installed the Plastic server on Windows the file won't exist and you'll have to create a new one. Linux users will always have a db.conf file.

So, if you're on Windows create a new file db.conf and write the following content:

<DbConfig>
 <ProviderName>
   sqlserver
 </ProviderName>
 
 <ConnectionString>
   SERVER=beardtongue\SQLEXPRESS;
   User Id=sa;Pwd=master;DATABASE={0};
 </ConnectionString>
</DbConfig>

Which is the configuration I use for my laptop.

As you can see I'm using a SQL Server Express server (beardtongue\SQLEXPRESS instance in the connection).

If you want to connect to a regular SQL Server you can use the following configuration:

<DbConfig>
    <ProviderName>
      sqlserver
    </ProviderName>

    <ConnectionString>
      SERVER=MORDOR;User Id=sa;Pwd=masterpwd;DATABASE={0};
    </ConnectionString>
    
    <DatabasePath>
      d:\repositories
    </DatabasePath>
</DbConfig>

Which is the configuration of one of our internal servers.

Of course remember to replace by your own server and authentication data!!

Note that in the second sample I've introduced DatabasePath which tell SQL Server the location to place its data and log files for Plastic SCM repositories. If you don't specify it SQL Server will use its default location.

Starting up Plastic
Once the db.conf file has been correctly set up, you've to restart the Plastic server.

On start up it will connect to the new database and create the databases repositories, workspaces and rep_1 (the default repository) if they're not there.

Using built-in Windows authentication
So far I've introduced how to connect using built-in SQL Server authentication which is basically telling Plastic to use a given user and password.

If you want to use built-in Windows authentication you'll have to modify your db.conf in the following way:

<DbConfig>
  <ProviderName>
    sqlserver
  </ProviderName>
 
  <ConnectionString>
    SERVER=beardtongue\SQLEXPRESS;
    trusted_connection=yes;
    DATABASE={0};
  </ConnectionString>
</DbConfig>

And restart Plastic.

The key is replacing the user and password data by trusted_connection.

There's an important tip to remember here: since you'll be normally running Plastic server under the system account on Windows, you'll have to make sure that account has rights to access your SQL Server database under trusted connection.

You can always change Plastic service configuration (using the services applet at your Administrative Tools on the Control Panel, to make it run under different credentials.

Troubleshooting the new connection
Setting up a SQL Server backend should be a really easy problem, but you know... problems can always show up!

If this is the case remember to check the loader.log.txt file at the server's install directory which contains the server's log.

The most common connection problems to check are:

You incorrectly typed the server

The user and password are not correct (integrated security)

The account running the Plastic server doesn't have rights to connect to SQL Server (trusted connection)

Configure SQL Server memory usage
SQL Server is a memory hog! It will try to eat as much memory as possible up to 2GB.

On a dedicated server it shouldn't be a problem, but if your server has to run not only SQL Server but also some other services (including the Plastic server!!) then you can end up in trouble!

Just to give you an example: I run SQL Server Express in my 1.5GB RAM laptop to host Plastic repositories. The system performs great if I limit SQL Server to 300 or 400Mb... but if you let it grow as much as it can... it will do and overall system performance will be really bad, including disc access (which is key for Plastic client when it has to write on your workspace) and so on.

So, how can you limit SQL Server memory?

If you're using SQL Server Express you'll have to do it with the sp_configure stored proc. If you use a regular SQL Server you'll be able to configure it from the admin application.

Running the stored proc is simple:

USE master
EXEC sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE

USE master
EXEC sp_configure 'max server memory (MB)', 300
RECONFIGURE WITH OVERRIDE

To limit it to 300Mb.

Please consider the following links for more information:

http://msdn.microsoft.com/en-us/library/ms180797.aspx

http://msdn.microsoft.com/en-us/library/aa196734.aspx

http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1299068,00.html#

http://www.teratrax.com/articles/sp_configure_max_memory.html

Migrating from a different database backend
So far I've just told how to configure Plastic to work with a SQL Server backend assuming you are going to start up from a clean situation.

But what if you need to migrate your current Firebird repositories into SQL Server?

Then your SQL Server experience will definitely help: Plastic uses standard databases and database structures, so you'll just have to import the data using a standard migration tool (a quick search on google will help like http://www.dbnetcopy.com/dbnetcopy/default.aspx) or using the built-in SQL Server migration tool.

We also have our internal migration tool available (although it is not fancy and beautiful :-( but just a useful and ugly command line utility) so if you are in a hurry just let us know.

Finish transaction
Well, we're done! As you can see there's no magic involved, and setting up the SQL Server database is pretty simple.

Try it yourself and check which backend fits better on your project.

Decompressing zip files with C#

Which is the fastest way to decompress ZIP files (fragments actually) using C#?

I tried with SharpZipLib vs zlib.net vs a wrapper on top of zlib 1.2.3.

Which one is faster?

I tried with the same test file, repeating 1000 times and these are the results:

$ time mono unzip.exe file ziplib 1000

real    0m4.491s
user    0m4.392s
sys     0m0.119s

$ time mono unzip.exe file sharp 1000

real    0m3.631s
user    0m3.550s
sys     0m0.090s

$ time mono unzip.exe file zlib 1000

real    0m1.754s
user    0m1.684s
sys     0m0.079s

Clear, right?

So, the zlib wrapper is two times faster than SharpZipLib which, in turn, is faster than zlib.net

For zlib wrapper I just called the uncompress method.

With SharpZipLib I used InflaterInputStream

InflaterInputStream st = new InflaterInputStream(file, new Inflater(true));

and for zlib.NET

zlib.ZOutputStream outZStream = new zlib.ZOutputStream(outStream);

Hope it helps!

Plastic SCM working with Trac II

Now we are going to see how the extension of Plastic SCM and Trac work, in this case using the second working mode: "task on changeset". As on the previous working mode, to use this extension, the first thing you will have to do is copy the ‘tracextension.dll’’ library to Plastic SCM client folder, and add the Trac extension lines on the client.conf.

And then, for the working mode we are explaining on this post: "task on changeset",
the following "tracextension.conf" file must be created:

<TracExtensionConfiguration>

  <XmlRpcUrl>
    http://localhost:8080/trac/login/xmlrpc
  </XmlRpcUrl>

  <ShowTicketUrl>
    http://localhost:8080/trac/ticket
  </ShowTicket>

  <User>tester</User>

  <Password>PR</Password>

  <Branchprefix>SCM</Branchprefix>

  <workingmode>TaskOnChangeset</workingmode>

</TracExtensionConfiguration>

Now that the extension is set up you can start working with it!

Depending on your company´s structure, either the project manager or a developer would be in charge of creating the tasks on Trac and then assign them to the developer who would work to solve them.

On this example we create two new tasks: task number 6 as shown on the image below, and we had previously added tasks.





Once the tasks have been created and assigned, the developer starts working, he makes his changes after checking out the items he is going to work on (either from Plastic GUI or from one of its IDE plug ins), and when the changes are done and he checkes his code in Plastic will open a window on which the user can include in the “checkin information”, it has the following appearance:



As you can see, on the top of this window the user can include his check in comments and the list of related items is shown.
The checked in tasks are included at the buttom, by selecting the option "Add new issue" the following window will appear:



Just by entering the task number as we include number 6 for the newly created task, the information of the Trac task will be shown.

Once the check in operation is done we can go to the changeset view and just by clicking on the changeset view and selected a changeset, we can see the Trac Extension information on the right, in this case, by selecting the created changeset, we can see on the extension information about its associated task, number 6; but that is not all...as using the "task on changeset" mode, one or more than one tasks can be related with one or more changeset, from this view we can also add new tasks to the changeset.



Now we have associated two tasks with changeset 23 as both of them have been solved on the same check in operation, by clicking on one of the tasks shown on the extension information we can either delete it necessary, or open the task on the Trac IDE, from which information such as the status of the task can be modified and it will be inmediately reflected on Plastic information of the extension as soon as it is refreshed!

Building task branches with CruiseControl

Welcome back PlastiKers! :-)

If you follow this blog or if you've reading about the latest changes in version control all around, you're probably familiar with task branches.

Simply put: it is all about keeping your mainline as stable as possible and isolating all changes in separate branches, as we introduced a few days ago.

Well, whether you already joined the new wave you probably have several questions. And one of them is:

what happens with my continuous toolset? how should I manage my builds now?

.

Instead of just monitoring a single branch (the trunk or main in most cases) now you've to build and test each branch separately, and only after it has been finished.

How can you achive that?

I'm going to propose a solution based on Plastic and CruiseControl.net (cc.net)

First, let's have a look at the whole set up involved.



We've a version control server and a CruiseControl server (they could run in the same machine, of course), and what we need to achieve is:

Find a way to track which branches are finished

Make CruiseControl trigger a build only when a branch is ready

Put a mark on the branch, somehow, so it doesn't get built again if everything works fine.

CruiseControl supports a number of version control systems and Plastic is on that list.

But what we need is not a regular version control block which is able to download code if new revisions are created, but perform something a little bit more specific.

In Plastic (and also in other SCMs out there) there's a very handful concept known as attributes. Attributes are values that can be attached to any controlled object.

We can create an attribute named branch_status and associate it to branches with a given value. The developer can set the branch_status value to closed once the feature or bugfix is finished, and this value will be used by the CC.net integration to trigger the build.

In Plastic the command would be (only one line):

cm find branch where
 attribute='branch_status'
 and attrvalue='closed'
 --nototal --format={name}

Of course instead of closed you can define another value.

And, once the tests are run, you can use the following command to set the branch as tested.

cm statt att:branch_status br:/main/feature101 tested

We'll use a couple of ruby scripts to implement the calls to the Plastic command line inside exec configuration blocks.

Take a look at the ccnet.config file

<cruisecontrol>
 <project name="helloworld">

   <modificationDelaySeconds>
     5
   </modificationdelayseconds>

   <sourcecontrol type="nullSourceControl"/>

   <triggers>
       <intervalTrigger
           name="continuous"
           seconds="10"
           buildCondition="ForceBuild"
           initialSeconds="10"/>
   </triggers>

   <tasks>

     <exec>
       <executable>ruby.exe</executable>
       <baseDirectory>D:\code\</basedirectory>
       <buildArgs>D:\code\findchanges.rb</buildargs>
       <buildTimeoutSeconds>10</buildtimeoutseconds>
       <successExitCodes>0</successexitcodes>
     </exec>

     <nant>
       <executable>nant.exe</executable>
       <baseDirectory>D:\code</basedirectory>
       <buildFile>default.build</buildfile>
     </nant>

     <exec>
       <executable>ruby.exe</executable>
       <baseDirectory>D:\code\</basedirectory>
       <buildArgs>D:\code\testedbranch.rb</buildargs>
       <buildTimeoutSeconds>10</buildtimeoutseconds>
       <successExitCodes>0</successexitcodes>
     </exec>

   </tasks>

 </project>
</cruisecontrol>
 

And the two ruby scripts:

one to find whether new branches are available

and the second to mark the branch as already tested.

findchanges.rb

input = `cm find branch
 where attribute='branch_status'
 and attrvalue='closed'
 --nototal --format={name}`

if ( input == "")
 print "no pending branches"
 exit(1)
end

branch = input.split(/\n/)[0]

selector =
 "rep \"default\" path \"/\" smartbranch \"#{branch}\""

File.open("selector.txt", "w") do |f|
 f.write(selector)
end

File.open("activebranch.txt", "w") do |f|
 f.write(branch)
end

system("cm setselector --file=selector.txt")

exit(0)

And testedbranch.rb

File.open("activebranch.txt", "r") do |f|
 branch = f.read()
 system("cm statt
   att:branch_status br:#{branch} tested")
end

And the picture depicting the whole process:



Which is very simple.

Please note I've used exec blocks in order to customize the entire process with simple ruby scripts, but we're plannig to add this capability to the Plastic SCM configuration block in cc.net.

And the branch explorer can highlight branches based on certain properties or attributes.



This way we have the skeleton to start up.

Next Steps
The goal would be setting up an automated process based on CruiseControl to build, test and report separated branches before they get integrated into the main line.

So the project configuration file: ccnet.config would have to extended from a hello world into a real script including testing tasks, deployment and so on.

Also reporting would be key, and specially adding data about which one is the branch being built and tested.

Hope you find it interesting!

How to use Plastic SCM and TechExcel DevTrack II

As we saw on the previous post on how to use Plastic SCM and DevTrack extension, there are two different options to work with the extension, depending on the working pattern your company is using, we are now going to look into the “Task on Changeset” option, which would be used for companies using the “Mainline development” pattern or “Branch per developer”.
In order to configure the extension for this working method you must set up the same “devtrackextension.dll” but in this case the file “devtrackextension.conf” changes, so it must have the following appearance:

<devtrackextensionconfiguration >
  <dtlinkplusurl>
    http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx
  </dtlinkplusurl>

  <user>terry-j</user>

  <projectid>daveProject</projectid>

  <systemid>daveSystem</systemid>   

  <branchprefix>issue</branchprefix>

  <dtbuginfobrowserurl>
    http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll
  </dtbuginfobrowserurl>

  <workingmode>TaskOnChangeset</workingmode>   
</devtrackextensionconfiguration>

Once the extension is set we can start working with it!

You must take into account that even though on the previous case: "task on branch", only one task in DevTrack was linked to one Plastic branch; in this case you can link one or more tasks with one or more changesets.In order to start working, the project manager must create tasks issues in DevTrack and assigned them.

Watch the image:




In this case we can see that:

The task number is 108 as we can see on the following image with the information of the newly created task, a defect in this case.

Check the image:




Now the assigned developer starts.

He would start working and edit the items needed in order to carry out the assigned task; he would go to Plastic, check out the files, edit and check them in: at this point Plastic will open a new window in order to include the “checkin information”.

The window has the following appearance:



Users can customize data:

Here the user can include his checkin, comments and link the check in operation (changeset) with the related task or tasks, as on the “Task per Changeset” one or more than one changeset can be linked to one or more than one task..
If we click on the “Add new issue” option another window will be opened, and from it we can choose the task to be linked.

In this case we link task 108 as shown on the following image:



And there we have it!

If we go to the “changesets view” we can find the information of the DevTrack tasks linked to each of the changesets, from this view we can also link more bugs to a changeset or delete previously added bugs, and as on the case of the “Task on branch” working mode, we can also go to DevTrack, make changes on the bugs and change them any time!



Hope you like it!

Plastic SCM working with Trac

Now it is the turn of another task tracking tool that Plastic provides extension with: Trac.

Plastic SCM for Trac offers full data mapping features allowing data to be associated between both tools, improving to a great extent your development´s traceability and control. On this post I am going to explain how to work with the extension on one of the working modes available: "Task on Branch".
In order to set up the extension you must follow a few simple steps:
First you have to copy the "tracextension.dll" file on the Plastic SCM client folder
Then you have to add the lines circle in red in the following image (which will indicate that Trac is the extension used) on the client.conf file:


And last but not least on the configuring steps, you must create a "tracextension.conf" file on which to indicate the extension parameters; this is where the working mode selected will be specified, the first one is the "Task on branch" option which is used to link one task in Trac with a branch in Plastic, in order to use this option the "tracextension.conf" file must have the following appearance:

<TracExtensionConfiguration>

 <XmlRpcUrl>
   http://localhost:8080/trac/login/xmlrpc
 </XmlRpcUrl>

 <ShowTicketUrl>
   http://localhost:8080/trac/ticket
 </ShowTicketUrl>

 <User>tester</User>

 <Password>PR</Password>

 <Branchprefix>SCM</Branchprefix>

 <workingmode>TaskOnBranch</workingmode>

</TracExtensionConfiguration>

And now everything is set to start working!

The person in charge of creating new tasks and assigning them (either the admin or one of the developers, depending on your organization) creates a new ticket in Trac; in order to create tickets in Trac you only have to go to the "New Ticket" option highlighted on the following figure. On Trac tickets can be subdivided into three different categories: defect, enhancement or task. The new ticket is numbered as ticket 3 and assigned to developer "michael" as you can see in the image below, developers can always run a ticket search on trac by status, developer assigned, etc. On the following image you can see that ticket number 3 is among the active tickets:

Once the ticket has been created and assigned, in this case developer michael will start working on it: he goes to Plastic and creates a new branch, giving this branch the same name as the Trac issue, with the defined prefix (defined on the tracextension.conf" file), which is scm in this case. In order to create the new branch the developer only has to go to the branch view and select "create new branch" and the following window will appear:

He would then name it scm003 in order to be linked with the Trac ticket; take into account that Plastic SCM handles smart branches, so when creating a branch you can set its base and whenever a developer switches to that branch it would remember its base.

Now to see how the extension works, if we go to the branch view and click on the "Show extended information option" on the top and select the newly created branch we can see on a menu on the right the information of ticket 3, which is the one linked to that branch displayed as shown on the following image:



The extension information shows the name of the ticket in Trac as well as its owner, title, comment and status. By clicking on it, an Explorer window with the associated branch ticket will opened and whenever the user wants to change the status of a certain ticket, he will only have to refresh it on the Plastic branch extended information and the new information will appear.

I will shortly also explain how to use Plastic SCM and Trac on the "task on changeset" working mode!

Xmerge tool to handle refactors (screencast)

If you ever read this blog before, you have probably noticed we post about branching and merging from time to time :-P
Ok, today I'm going to introduce the latest crazy idea we just had: Xmerge (cross-merge).

What's cross-merge? Simply put: it is just a tool to help developers merging code that has been moved and modified in parallel. This is very likely to happen when you refactor your code.

So, suppose you've an initial file like this one:



And then two developers start making changes on it in parallel (which is a very good idea if you don't want them to wait on each other... :-P):

The first developer changes some code on the first method, and the second one moves the code.





What will happen when you try to merge the changes back?

The merge tool won't detect the moved code, but think some code has been removed and some code has been added. So, you'll end up editing code manually and copying and pasting code blocks around. Painful.



What if the tool could give you some support?

The best thing would be if it just detects the code has been moved, but it means it will have to run some sort of parsing, which is not the easiest thing to do, it becomes language dependent and so on (and this is what we're working on right now, so stay tuned!).

But, what if it justs let's you find yourself the moved code and then the tool is able to manage the dirty work? You'll save some ugly cutting and pasting, right?

It would be great to have something like the following: the tool detects "something has happened", then it prompts you to find the moved code, then it runs a "sub-merge" with only the affected contributors.



You run the sub-merge, solve the potential conflicts, and the tool will replace your selection with the new merged code.

Easy, right?

We're working on a new release of the Plastic merge tool, so you can see it in action in the following screencast!!



Next steps?

Yes, there're a few:

What happens when code is moved into a different file? We're working on it.

Auto detecting moved code

Looking for moved code in files

Stay tuned!

4 steps to make version control shine

In the beginning everything was flat.



Now, fortunately, it isn’t.



Background
Ok, why I’m writing this? Well, this week I had the chance to take a look at two great presentations from the OSCON 2008:

The first is from Mark Shuttleworth (Canonical, Ubuntu), titled Beyond Agile: Enabling the Next Wave of Software Development Methods, and talks about a number of very interesting topics such as Lean Software Development. You can find the slides here.

What I really liked was slide 17 where he says:

Branching and Merging
  Keep trunk pristine,
    Keep features flowing,
      Release on demand.

And slide 20 where he mentions:

Pre-Commit Testing
  I see you knocking
    but you can't come in.

I also liked Code Reviews for Fun and Profit, from Alex Martelli (Google) which you can find here .

He mentions the following on slide 26:

ideally, CR mailing should happen BEFORE
actual commit/push of change-set to the
codebase -- upholds trunk/head/tip quality

Which also does look interesting, right?

So, I came up with this post.

The rules

Let’s try to find which ones are the key rules to make version control shine in the post-agile era:

Rule 1: Keep your main branch (trunk) pristine. Your main branch is your project! Don't use it as a garage (full of garbage) to park all the fixes and new features. Use branches instead!

Rule 2: Isolate changes in branches. It is a consequence of Rule #1. Place each bugfix and new feature inside its own branch. It will help keeping the main line clean, and it gives you all the power of real parallel development. It's also great for task switching and keeping track of intermediate changes.

Tip: Associate your branch with a task in your issue tracking system (Bugzilla, Mantis, Jira ...) and close the full cycle.


Rule 3: Commit often, more often than you do now! If you develop on the main branch you won't commit every 5 minutes, changes often take longer! If you have your own branch for the task, you're free to commit as many times as you want to... and then you get private change history.

Rule 4: Review changes before they go to the mainline. In main branch development (and continuous integration) you run the test suite after the changes are merged. Don't! This is too late, code is already broken! Take the best out of your SCM tool, review your changes before integrating!



The good news is: there are tools supporting this model both on the commercial and the open source worlds: plastic, accurev, git (bazaar?)...

The bad news is some of the most extended tools out there can’t.

A new era is coming... get ready!

How to use Plastic SCM and TechExcel DevTrack I

As you may have already seen on previous post, Plastic SCM provides with the option of using it integrated with different task tracking tools as it integrates with some of the most extensively used systems in the market, you can have a look at the list of options here.

One of them is TechExcel DevTrack!


On this post I am going to explain with examples, how to use Plastic SCM integrated DevTrack.

First of all we have to know that Plastic SCM not only integrates with this system, but also offers customizable options for the integration.

Why do we provide with different options? So you can use the one that better adjusts to your working pattern: Let´s see the “Task on Branch” working mode on this post.

The first step in order to set up the DevTrack extension on your client machine you have to copy “devtrackextension.dll” on the folder where Plastic SCM client is installed and add the following lines (circled in red) in order to indicate the client to use this extension:



And you would also need to create a file “devtrackextension.conf”, its appearance by default is the following one:

<devtrackextensionconfiguration >
  <dtlinkplusurl>
    http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx
  </dtlinkplusurl>

  <user>terry-j</user>

  <projectid>daveProject</projectid>

  <systemid>daveSystem</systemid>
  <branchprefix>issue</branchprefix>
  <dtbuginfobrowserurl>
    http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll
  </dtbuginfobrowserurl>
</devtrackextensionconfiguration>

Finally, you need to make sure that:
the devtrackextension.dll file is on the Plastic SCM client folder.

And by default the “Task on Branch” option is set, or you can specifically set it as follows:

<devtrackextensionconfiguration>
  
  <dtlinkplusurl>
    http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx
  </dtlinkplusurl>

  <user>terry-j</user>
  <projectid>daveProject</projectid>     
  <systemid>daveSystem</systemid>  
  <branchprefix>issue</branchprefix>
  <dtbuginfobrowserurl>
    http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll
  </dtbuginfobrowserurl>

  <workingmode>
    TaskOnBranch
  </workingmode> 

</devtrackextensionconfiguration>

Now that the extension is set up:

The first step to start working with it would be creating a new bug on our task/bug tracking system; DevTrack in this case.

In DevTrack tasks can be submitted as either defects or new features, and they can also be classified into several categories such as Minor Improvement, Future Enhancement, Discrepancy Report, etc.


As the new task is created, it is on state “NEW” and assigned to a developer. “
The title given to this new task is "Additional options: Customization".
By saving the task we can see the number D given to it, in this case it is issue number 106, and we could indicate the system to send an email to the developer in order to let him know that we have assigned him a new task.



When the assigned developer, in this case Paul, is ready to start working on task 106, he will easily create a new branch and name it according to the task created on DevTrack, and add his comments accordingly.

You can also set the branch base and it will be remembered by the branch every time a user switches to work on it... if you are interested on learning more about Plastic smart branches you can find it here.



After the branch has been created, by going to the top left on the branch view we can display the extended information of branches, which will show information on the DevTrack related bug when selecting a branch.

On the following image we select the newly created branch /scm00106 and on the right hand side we can immediately see the information of issue 106 on DevTrack: its ID, owner, title and comments are shown on the custom view:



And as soon as the task is accomplished we double clicking on the dialogue or just click on the extension button, which will take us to the DevTrack tasks, where we can change the status, which will be refreshed on Plastic:




Easy!, Hope you like it!