I just realised that yesterday was the birthday of this blog and in two days it's a year since the first release (that was 0.1.3, I'm not sure what happened to 0.1.0,1,2)
It feels like so much longer!
Thanks to everyone who has supported Lizard though comments and suggestions, please keep it up,
Thanks,
Ian.
Thursday, 8 January 2009
Merging and Rollbacks
Recent work has been now been focussed on finishing of the functions that I've been planning from the beginning, that got left behind for the extension re-write.
No new builds yet, but the source is coming along. I've had to spend some time re-familiarising myself with the folder diff engine, the gnu diff integration and the scintilla.Net controls. Finally I cleared up some rather tatty code behind the 3-way diff visualiser. This is neatly laid out in a set of classes under LizardDiff.Diff3Docs, one class per view, instead of a big single mess.
New features are:
The next step is to manage applying the generated patch file to another folder/branch and list updated files and conflicts, and allow conflict resolution through the diff/merge tool. This be the 'Lizard Merge' tool, and will allow merging across any folders, 2nd/3rd, etc generation branches as well as strict TFS 1st generation branches. This will also become the 'Lizard Rollback' tool by taking the difference between a higher and lower change set (rather than lower to higher) and applying to the higher version.
All the current work is being checked into the .Net 2.0 branch, and will be merged into the 3.5 branch (using Lizard Merge) prior to the next.
I'll have to check my notes, but I think that will make LizardTF feature complete and ready for Beta!
No new builds yet, but the source is coming along. I've had to spend some time re-familiarising myself with the folder diff engine, the gnu diff integration and the scintilla.Net controls. Finally I cleared up some rather tatty code behind the 3-way diff visualiser. This is neatly laid out in a set of classes under LizardDiff.Diff3Docs, one class per view, instead of a big single mess.
New features are:
- Uncontrolled Changes in Lizard Review - see changes to files not checked out, new files added to TFS controlled folders but not 'added' and files deleted from the file system but not from TFS. This was a popular request.
- Create Patch from the Folder Compare screen; you can build/save a gnu unified diff based patch file from the difference found by the comparer.
- Proper (and improved) version browsing from the Folder Compare screen
- Rename Tracking when comparing file system to TFS or TFS to TFS when 'to' and 'from' have the same repository path. This is done be parsing the changesets between 'to' and 'from' for renames. These are displayed in the output.
- 2 Way Diff now shows numbers of Inserts, Changes and Deletions.
The next step is to manage applying the generated patch file to another folder/branch and list updated files and conflicts, and allow conflict resolution through the diff/merge tool. This be the 'Lizard Merge' tool, and will allow merging across any folders, 2nd/3rd, etc generation branches as well as strict TFS 1st generation branches. This will also become the 'Lizard Rollback' tool by taking the difference between a higher and lower change set (rather than lower to higher) and applying to the higher version.
All the current work is being checked into the .Net 2.0 branch, and will be merged into the 3.5 branch (using Lizard Merge) prior to the next.
I'll have to check my notes, but I think that will make LizardTF feature complete and ready for Beta!
Sunday, 9 November 2008
Swiftly followed by 0.3.1
I've ironed out some install issues, hopefully now it is much simpler to install, get the Tortosie Overlays installed, clean up old installs etc.
The current checked in source code has an extra option to replace the standard Tortoise overlays for 'Unversioned' and 'Ignored' with the LizardTF ones for 'Out of date' and 'Checked-in but modified'. I was going to replace the release with this but I have to check them first, so they are in as a planned release 0.3.2.
Most of my work has been trying to get a decent build for those who want to download the source and build their own. To this end there are various prebuild and postbuild .bat files that stop and start explorer and movc various dependeny files around. It's all a lot more fiddly than I wanted. A lot of the problems come from the main build having to always target x86 (so they can call the TFS client API dlls), and the extentions having to target the right platform for the OS. I've been using the 'Batch Build' option to build both x86 and x64 versions of the extensions and x86 versions of everything else, except the Lizardx64Registry project. This is a command line .exe app that sets/tests various registry settings. If you are running a 64bit OS this is needed to change the main registry that the x64 extensions and TortoiseOverlays use. This is needed because as the main application is all built for x86 it only accessed the WoW parts of the registry. Only by calling an Out-Of-Process command line can I easily modify HK_LocalMachine for x64 applications.
I've changed the way the meta-data cache folder is structured. Rather than all the folder path hashes going straight into the root meta-data folder, I've split them up by first charactor, then second charactor. This is to prevent getting overly populated folders. Any one who was using Lizard 0.3.0 will need to re-parse their folders, and should delete any folder with a name more the 1 char long from the meta-date folder.
I think it's all in place now, I think all the necessary files are in the right places. I'll hopefully be testing on x86 hardware during the week. Everything seems good on x64 so far.
Also new is the whole new build for dotNet 3.5 - and associated VS9 solution branch. All the source is the same as the dotNet 2.0 branch except the .sln, .csproj, .vcproj and .vdproj files. I can't see any real benefit of using Linq or lambda expressions in Lizard right now, so it will probably stay that way.
I've started using the WorkItem support provided by CodePlex, so feel free to raise any issues as WorkItems, or just add a comment to the Blog. Now the really big structural change is out of the way I should be turning aroung smaller issues much faster.
Please let me know if you have problems gettings either the msi or source code up and running, and I'll do what I can.
The current checked in source code has an extra option to replace the standard Tortoise overlays for 'Unversioned' and 'Ignored' with the LizardTF ones for 'Out of date' and 'Checked-in but modified'. I was going to replace the release with this but I have to check them first, so they are in as a planned release 0.3.2.
Most of my work has been trying to get a decent build for those who want to download the source and build their own. To this end there are various prebuild and postbuild .bat files that stop and start explorer and movc various dependeny files around. It's all a lot more fiddly than I wanted. A lot of the problems come from the main build having to always target x86 (so they can call the TFS client API dlls), and the extentions having to target the right platform for the OS. I've been using the 'Batch Build' option to build both x86 and x64 versions of the extensions and x86 versions of everything else, except the Lizardx64Registry project. This is a command line .exe app that sets/tests various registry settings. If you are running a 64bit OS this is needed to change the main registry that the x64 extensions and TortoiseOverlays use. This is needed because as the main application is all built for x86 it only accessed the WoW parts of the registry. Only by calling an Out-Of-Process command line can I easily modify HK_LocalMachine for x64 applications.
I've changed the way the meta-data cache folder is structured. Rather than all the folder path hashes going straight into the root meta-data folder, I've split them up by first charactor, then second charactor. This is to prevent getting overly populated folders. Any one who was using Lizard 0.3.0 will need to re-parse their folders, and should delete any folder with a name more the 1 char long from the meta-date folder.
I think it's all in place now, I think all the necessary files are in the right places. I'll hopefully be testing on x86 hardware during the week. Everything seems good on x64 so far.
Also new is the whole new build for dotNet 3.5 - and associated VS9 solution branch. All the source is the same as the dotNet 2.0 branch except the .sln, .csproj, .vcproj and .vdproj files. I can't see any real benefit of using Linq or lambda expressions in Lizard right now, so it will probably stay that way.
I've started using the WorkItem support provided by CodePlex, so feel free to raise any issues as WorkItems, or just add a comment to the Blog. Now the really big structural change is out of the way I should be turning aroung smaller issues much faster.
Please let me know if you have problems gettings either the msi or source code up and running, and I'll do what I can.
Sunday, 19 October 2008
LizardTF alpha0.3.0 Has Landed!
Release posted and source code in Codeplex is up to date.
I will be testing the release over the next few days.
New features include:
All c++ Explorer extensions - no more loading the CLR into the shell
Multi server support - Have working folders for Codeplex and local TF Servers
Paged history - get revision logs in smaller chunks
History through branches - see history belonging to originating branches
More to follow...
I will be testing the release over the next few days.
New features include:
All c++ Explorer extensions - no more loading the CLR into the shell
Multi server support - Have working folders for Codeplex and local TF Servers
Paged history - get revision logs in smaller chunks
History through branches - see history belonging to originating branches
More to follow...
Saturday, 4 October 2008
By 'eck, they don't half make it difficult sometimes...
Progress has been slow, between two many DIY jobs and to much work at work, Lizard 0.3 is proving a bit hard to get out. One of the reasons is that I'm not much of a c++ programmer, or rather I'm not use to unravelling c++ documentation/examples on the internet.
What follows will probably be of little interest to anyone except those from c# (or VB, or Delphi etc) background who are trying to find their feet with c++ and COM.
I wanted to read the location of the Lizard meta-data folder from the registry (it's been hard-coded up till now). I quickly found I needed the CRegKey.Open and CRegKey.QueryStringValue methods, but wanted to see some examples to see how they really worked. After spending way too much time reading 163 different variations on a theme, I wrote my own based on this article from the Geak Technologies web site (thanks chaps, who ever you are). The problem I have with c++ examples and tutorials is they hardly ever show all the #includes you need or which libraries you need to add to the linker, and of course, it being c++, always disagree with what sort of string to use. Always use CString! std::string is superior! Real programmers use... etc etc. Some forums had posters getting quite angry that someone suggested the 'wrong' sort of strings for this or that, but I'm guessing from the multitude of opinions that there isn't just one (or even two or three) right way.
My extensions use CComBSTR a lot, this will probably make a lot of people purple with rage, but they seem to be the easiest if you want to interact with COM objects and are using ATL.
Any way, for any one who got here because they searched for 'c++ Registry Access, Key, Path'
here is some code:
#include "stdafx.h"
#include
using namespace ATL;
#include "RegistryAccess.h"
CComBSTR GetRegistryKeyValue(CComBSTR regKey, CComBSTR valueName)
{
CRegKey key;
CComBSTR value="";
long nError = key.Open(HKEY_CURRENT_USER, regKey.m_str, KEY_READ);
if(nError == ERROR_SUCCESS)
{
DWORD dwBufferSize = MAX_PATH;
LPTSTR v = new TCHAR[MAX_PATH];
key.QueryStringValue(valueName.m_str, v , &dwBufferSize );
value.Append(v,dwBufferSize);
}
return value;
}
If you're writing an ATL based project then #include might well already be in your 'stdafx.h' but I wanted to include it here because it defines CComBSTR and CRegKey. This code works but really didn't warrant two hours of my life.
Yeah, I know I should get a good book and learn this stuff properly, know what the relationship between a LPCTSTR and a *PCH is, and memorise every typedef in every .h file in the c++ sdk, but that is for another day.
Let the flaming begin!
What follows will probably be of little interest to anyone except those from c# (or VB, or Delphi etc) background who are trying to find their feet with c++ and COM.
I wanted to read the location of the Lizard meta-data folder from the registry (it's been hard-coded up till now). I quickly found I needed the CRegKey.Open and CRegKey.QueryStringValue methods, but wanted to see some examples to see how they really worked. After spending way too much time reading 163 different variations on a theme, I wrote my own based on this article from the Geak Technologies web site (thanks chaps, who ever you are). The problem I have with c++ examples and tutorials is they hardly ever show all the #includes you need or which libraries you need to add to the linker, and of course, it being c++, always disagree with what sort of string to use. Always use CString! std::string is superior! Real programmers use... etc etc. Some forums had posters getting quite angry that someone suggested the 'wrong' sort of strings for this or that, but I'm guessing from the multitude of opinions that there isn't just one (or even two or three) right way.
My extensions use CComBSTR a lot, this will probably make a lot of people purple with rage, but they seem to be the easiest if you want to interact with COM objects and are using ATL.
Any way, for any one who got here because they searched for 'c++ Registry Access, Key, Path'
here is some code:
#include "stdafx.h"
#include
using namespace ATL;
#include "RegistryAccess.h"
CComBSTR GetRegistryKeyValue(CComBSTR regKey, CComBSTR valueName)
{
CRegKey key;
CComBSTR value="";
long nError = key.Open(HKEY_CURRENT_USER, regKey.m_str, KEY_READ);
if(nError == ERROR_SUCCESS)
{
DWORD dwBufferSize = MAX_PATH;
LPTSTR v = new TCHAR[MAX_PATH];
key.QueryStringValue(valueName.m_str, v , &dwBufferSize );
value.Append(v,dwBufferSize);
}
return value;
}
If you're writing an ATL based project then #include
Yeah, I know I should get a good book and learn this stuff properly, know what the relationship between a LPCTSTR and a *PCH is, and memorise every typedef in every .h file in the c++ sdk, but that is for another day.
Let the flaming begin!
Sunday, 14 September 2008
TFS installation nightmares
I was running my test TFS server on an eval version of SQL server. I now have a full version, the eval ran out so I thought let's upgrade! Ha!
You can upgrade SQL server versions, but only if the original service is running. No good if your eval has expired! Started installing everything from new, but getting silly errors somewhere around the SPS set up. This is about the 4th time I've installed TFS and it's still a pig.
Meanwhile I thought it was about time I used CodePlex's TFS server with LizardTF to see how it works. There is now source code available from:
http://www.codeplex.com/lizardtf/SourceControl/ListDownloadableCommits.aspx
It is very bleeding edge at the moment as I settle in the new c++ shell extensions.
Playing with my source code in CodePlex made me make some optimisation work a high priority, and I also got a bit annoyed with the '_ltf' folders, a system copied from TortoiseSVNs '.svn' folders. I have now moved the meta data to it's own 'special' folder, thus keeping the actual working folders clear of Lizard meta data, allowing easier zipping, browsing etc etc. The metadata for each working folder is now stored in a special folder (configurable) using a hash of the working foldername to flatten the hierarchy. I have just written (borrowed from MSDN MD5 sample, and another Base64 sample) a c++ folder path hasher, that miraculously matches the one I wrote in c# using System.Security.Cryptography.MD5CryptoServiceProvider and Convert.ToBase64. This allows the shell extensions to keep quiet unless metadata exists, leaving performance for browsing non-TFS folders unchanged. Browsing TFS working folders over the internet to CodePlex is a little slow (4-6 seconds for a folder with 30-40 files in it) but it is usable. I'll be thinking of how to allow customising the functionality for slow connections.
I think I've got the extensions pretty stable now, so will be looking to get a build out soon, Alpha 0.3.1, I guess.
May be then I can get on with some of the functionality I've meaning to do for over a year now....
You can upgrade SQL server versions, but only if the original service is running. No good if your eval has expired! Started installing everything from new, but getting silly errors somewhere around the SPS set up. This is about the 4th time I've installed TFS and it's still a pig.
Meanwhile I thought it was about time I used CodePlex's TFS server with LizardTF to see how it works. There is now source code available from:
http://www.codeplex.com/lizardtf/SourceControl/ListDownloadableCommits.aspx
It is very bleeding edge at the moment as I settle in the new c++ shell extensions.
Playing with my source code in CodePlex made me make some optimisation work a high priority, and I also got a bit annoyed with the '_ltf' folders, a system copied from TortoiseSVNs '.svn' folders. I have now moved the meta data to it's own 'special' folder, thus keeping the actual working folders clear of Lizard meta data, allowing easier zipping, browsing etc etc. The metadata for each working folder is now stored in a special folder (configurable) using a hash of the working foldername to flatten the hierarchy. I have just written (borrowed from MSDN MD5 sample, and another Base64 sample) a c++ folder path hasher, that miraculously matches the one I wrote in c# using System.Security.Cryptography.MD5CryptoServiceProvider and Convert.ToBase64. This allows the shell extensions to keep quiet unless metadata exists, leaving performance for browsing non-TFS folders unchanged. Browsing TFS working folders over the internet to CodePlex is a little slow (4-6 seconds for a folder with 30-40 files in it) but it is usable. I'll be thinking of how to allow customising the functionality for slow connections.
I think I've got the extensions pretty stable now, so will be looking to get a build out soon, Alpha 0.3.1, I guess.
May be then I can get on with some of the functionality I've meaning to do for over a year now....
Monday, 25 August 2008
Coming together again...
I've had a break, a week in California and a week on Cape Cod, I'm back in England, I've taken my study apart, laid a new floor, and put it back together again.
I've just picked up the pieces of re-writing the explorer shell extensions in c++ (so that explorer won't load the .Net run-times and get itself into trouble). I hope Microsoft support .Net shell extension in Windows 7.
A break did me some good, and things have progressed well since.
The new extensions are working well, all the icon overlays are in place using TortoiseOverlays. I know I said they were done in July, but I was getting a bit ahead of myself. The codes much neater now, and client/server operations minimised. The only issue I have at the moment is that the 'Normal' overlay doesn't appear, when I attach the same Lizard handler to a different TortoiseOverlay handler all works fine, so I think there's either something up with the TortoiseOverlays code (unlikely) or something up with the config (more likely) but it all looks right, and is the same for all the working ones.
I've got to optimise the item data requests for the additional list view columns, but the techniques used for overlays will work again here, so its just implementation. I'm going to leave the property page out for now to try a get a build out. I'm not entirely happen about the build process with the c++ project. For some reason regsvr32 always fails for the output dll, so COM registration is manual. I'll probably post the source, a good build and a .reg file initially and leave it to those who want to to create their own build process.
I'm away next weekend, but realistically I'm hoping to get something published but mid september. I'm also planning to provide support for assigning different TFS servers to working folders and up loading all the source to the Codeplex TFS server and testing Lizard against that.
After that, back to features list, and on to a Beta release!
I've just picked up the pieces of re-writing the explorer shell extensions in c++ (so that explorer won't load the .Net run-times and get itself into trouble). I hope Microsoft support .Net shell extension in Windows 7.
A break did me some good, and things have progressed well since.
The new extensions are working well, all the icon overlays are in place using TortoiseOverlays. I know I said they were done in July, but I was getting a bit ahead of myself. The codes much neater now, and client/server operations minimised. The only issue I have at the moment is that the 'Normal' overlay doesn't appear, when I attach the same Lizard handler to a different TortoiseOverlay handler all works fine, so I think there's either something up with the TortoiseOverlays code (unlikely) or something up with the config (more likely) but it all looks right, and is the same for all the working ones.
I've got to optimise the item data requests for the additional list view columns, but the techniques used for overlays will work again here, so its just implementation. I'm going to leave the property page out for now to try a get a build out. I'm not entirely happen about the build process with the c++ project. For some reason regsvr32 always fails for the output dll, so COM registration is manual. I'll probably post the source, a good build and a .reg file initially and leave it to those who want to to create their own build process.
I'm away next weekend, but realistically I'm hoping to get something published but mid september. I'm also planning to provide support for assigning different TFS servers to working folders and up loading all the source to the Codeplex TFS server and testing Lizard against that.
After that, back to features list, and on to a Beta release!
Subscribe to:
Posts (Atom)