Sunday, 9 November 2008
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
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
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:
using namespace ATL;
CComBSTR GetRegistryKeyValue(CComBSTR regKey, CComBSTR valueName)
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 );
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
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:
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
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!
Saturday, 12 July 2008
But a quick update :-
The c++ extensions are still coming along. The additional columns are working nicely. The icon overlays are working - and using the TortoiseOverlays dll, so Lizard will run nicely with TortoiseSVN/CVS installed - thanks to HarriHasler for the tip on that one - and for taking me to task for the c# extensions in the first place.
At the moment I have a weird problem where the menus display great, the first item works, but clicking other items causes menu commands from the main menu to be invoked, not the sub menu. I keep looking through the code for the error but just can't spot it.
Once that is done I just need to re-code the properties page, there are some good examples on CodeProject for property pages so hopefully it won't be too bad.
I am not enjoying this at all though! The mixture of c++, COM and running within the Explorer process and the inherent debugging issues does not make for a fulfilling evening of coding! How many ways can you screw up string handling in c++? I think I've managed about 6,000 so far.
I really want the ability to merge across arbitrary folder and not just direct branches, so that will be the next area to tackle. I hope once the extensions are re-done my enthusiasm will rally!
Sorry to anyone waiting... it will come soon!
Monday, 26 May 2008
So I've been learning some c++.
I've got the menus working! and I'm hoping that most of the pain is now behind me (Getting to grips with c++ libraries and linker errors is not all that fun). But now there's a tcp/ip based transport in place (pretty basic string stuff) for Lizard so serve up the info, and my c++ extension classes are connecting up okay and passing in requests and processing results. I've got Michael Dunn's excellent articles on shell extensions from CodeProject, which I already used as a basis for the c# code, so I'm hoping to get the full set done over the next month, and then pray I haven't caused any major memory leaks along the way. It's a long time since I've coding without built in memory management.
On another note, I have finished (I think) the 'History through Branches' option on the history screen, this does pretty much what the name suggests, and shows the history from the originating branch(es). This was more of a pig than I had hoped, especially when I was trying to keep the selected block sizes all working. It's all looking good, but I haven't given it a full test on a big, real source repository with some complex branching. This should be complete soon.
The Lizard systray icon will (next release) have a little menu to jump straight into a beefed up repository browser, work items or label search. The repository browser now has full support for deleted items and you can browser/compare at any folder, branch or version and view or get any items/folders.
There is a currently experimental feature that uses FileSystem watchers and can automatically check out files that are changed, this seems to be working well, but I need to see what happens when used at the same time as TeamExplorer is doing a large get.
Work as slowed up a bit after crunching through a lot of functionalty, now I'm down to the trickier bits, but once the new shell extensions are done I want to look to releasing once a month, and hopefully will move to Beta (wahey!) quite soon.
The feedback I've had so far as been quite positive, so thanks for that. Please do let me know if something is broken, not right, too slow or difficult to use; and please let me know if you have any desired features not currently present or planned.
I'm hoping to open this project up to collaborators once it becomes Beta and I have a chance to go through, tidy and comment some of the code, so let me know if you think this might be your sort of thing.
Sunday, 13 April 2008
Also in this time my VS-TFS 2008 Beta licence expired and it took a while before I could set up a shiny new VM server running the old 2005 version. I thought it ran out in April, but hey ho.
I need to do a whole bunch of screen shots, really, for this release as there are lots of new screens to handle labels, WorkItems, shelving, unshelving, branching and a Repository Browser, hopefully I'll post this over the next week. But just right-click a file/folder that belongs to a workspace in Explorer and have a look. Hopefully it's fairly intuitive if you're use to TFS/Team Explorer or SVN/TortoiseSVN
All in all, Lizard is going rather well. This release isn't as complete as I'd like it to be, but I thought I should get something out. Otherwise it's easy to keep putting off and putting releasing anything. Obvious omissions from this release that I'll address soon are: Deleting labels, right click menu options from the Review screen, Move and Rename options. The labeling screens haven't been tested very hard.
Next up, the review screen will show files that have not been checked out, but have been changed (with an option to check them out) - handy if you're not using VS and you're a bit lazy and I'll finally sort out the rename/move conflict resolution and branch merging.
The 'fun' bit of this release was changing the already 'interesting' list/tree view of the review screen to use VirtualMode (that is creating ListViewItems on demand, rather than all up front). The MS implementation of this feels a bit last minute as although your list views are much faster, they don't support groups, images or checkboxes, Lizard uses all three, but the images and checkboxes were already custom drawn, now the groups are custom handled too. One happy consequence was that it actually made column sorting easier. The whole thing now feels much slicker and smoother, especially when dealing with large file sets, and the tree expansion and collapsing looks much better too.
Sunday, 9 March 2008
The main difference is that all functions are driven from the working copies (via windows explorer) rather than from a repository (server) view. I prefer this way of working as once checked out, you are working on the working copies, not the repository. I admit the distinction is a subtle one, but quite important if you want to work off-line, which is something I'd like to add to LizardTF - though I notice now that it is included in TFS2008 (see previous post)
LizardTF integrates into Windows Explorer, and shows TFS items current status with icon overlays, so as you browse your files you can immediately see what is checked in, checked out, changed, out of date, potentially conflicting or recently added. Extra detail columns show TFS version numbers, status and locks, an additional properties page shows a quick history and full status - all from the regular explorer. Extra context menus provide access to all the repository functions.
LizardTF shows both in windows explorer and in review screens all conflicts, out of dates, check-outs with local changes, and check-outs without changes(a distinction Team Explorer doesn't make).
The review screens only show changes about the files/folders selected, rather than all across the repository as in Team Explorer. Though if you select a root folder, you will see all changes, obviously.
When you select 'Check-in' in Team Explorer it lists everything that is checked out. Visual studio will check things out automatically, some won't have changed. This makes a quick sanity check review before committing a changeset rather time consuming. LizardTF clearly shows files that have changed seperately from ones just checked out.
Team Explorer only mentions conflicts after you attempted a check in. You then get the option to fix conflicts, but it does not prompt to re-attempt the check in once all are resolved. You will have lost all check in comments, notes and associations. LizardTF highlights conflicts at once, and doesn't close the check in screen unless you tell it to.
Team Explorer sometimes insists that there are no pending changes, even though you know there are. You have to use the command line to get out of this situation. (Or maybe re-start Visual Studio - but that can be a pain). LizardTF has never done this (yet) and can resolve this problem with Team Explorer encounters it.
The comparison tool has more view options, than the Microsoft one, offering side-by-side and inline, and differences only with optional context - good for quick reviews. It also allows you to reload either side from either any file system file, or any repository item. Once a repository item is loaded you can easily reload to any revision with out closing and re-opening. This makes searching for where changes occurred much simpler.
The merge tool is, in my opinion a lot clearer than Microsoft's tool, it also offers side-by-side-by-side view, side-by-side with output beneath, and side-by-side with output in a separate window for maximum on-screen visibility. All merges can be undone/redone, all conflicts resolved / reset and resolved again, all with distinctive mark-up and tool tip text to show the state of any line.
Lizard TF also offers what Tortoise calls blame, and Microsoft have called Annotate in their 2008 release of Team Explorer, this shows the originating changeset for every line in a file, which can be very useful when you find a line that seems insane, but also necessary.
LizardTF History screen shows changeset details in second pane, so you don't have to launch a seperate model form to see what is in a changeset, you can then immediately navigate to the history of any item included in changeset, navigate back again, or up a folder level. This makes history browsing very quick and fluid.
The integration into Visual Studio makes Team Explorer very annoying when it comes to model forms - you can't enter a WorkItem, or view histories once you've opened a check-in dialog, for example. LizardTF uses very few modal forms.
Team Explorer does have better progress bars, but I think they might have better access to progress events than are offered by the public API, because I've looked and can't find the message events! (I will keep looking...)
There are screen shots throughout this blog, but I need to get a decent up to date set.
That's all for now. In the future we will have baseless merging, rollbacks and more...
Already written for the next release: branching, shelving, unshelving, some performance optimisations (for big Gets and Explorer browsing) and merging changes into unrelated targets.
Sunday, 2 March 2008
Just for the record, Microsoft copied Lizard, even if their code was written some time before mine. And I still like mine the most!
I've been making Lizard less chatty with the server when Explorer browsing to speed things up a bit. Lizard *does* take local metadata similar to SVN clients, it can work out if and how a file has changed without contacting the server. I can (and do) avoid server calls in a lot of instances but there is a downside. Only the server can know if another client has changed a file and checked it in. I like that LizardTF shows out-of-date files without being specifically asked to, but it requires a call to the server every time a folder is browsed in explorer. To be honest both on my home setup (running TFS on a virtual PC on the one box) and at work (big TFS server in a rack somewhere) things seem pretty brisk, and it's not really a big worry, but I would like to use LizardTF with Codeplex projects and I haven't actually tried it yet. There are several reasons. 1) Although I mean to make Lizard multi-server, I haven't done so yet. 2) The Lizard source code lives in a TFS server on a virtual PC, this is also what I test against (probably not the best idea, but there you go), and 3) I don't won't to get too distracted. The project has already grown a lot with the diff and merge tools and I want to complete the functionality as-is first.
I guess when I make Lizard multi-server I'll allow users to choose connection level for each registered server. I would also like to provide a full 'off-line' mode with re-sync but I think that will be somewhere down the line.
I do think TFS version control is good and I hate source-safe with a passion, but I miss the elegant simplicity of SVN.
Tuesday, 26 February 2008
Playing with the new release today I discovered the exe/dll version differ was keeping locks on any .net assemblies as it loaded the whole assembly, rather than just the name. Which is rather unacceptable so there is a new 0.2.2 release on Codeplex now. While I was there I also made it so you could drop and drag other dll/exes onto the form and it would show the version info for those.
Then I discovered that when I added the Work Items list to the History Browser I inadvertently detached the click, double click and right click events from the details list, so I've fixed that now too.
Hopefully that's it until merging, branching and renaming conflict resolution is complete.
Monday, 25 February 2008
I've been using LizardTF at work where we have a big repository with lots going on, and I like to have a non-Visual Studio client - it's why I started this in the first place, and I noticed some annoying issues.
- Newly added repository items not yet in the local workspace weren't showing in the review/get list
- Conflict resolver crashed if a merge or conflict was on the last line
- Context menu 'Compare with...' wasn't using the exe/dll display when it should
- History browser didn't show associated Work Items for a change set.
- History button on property page was broken.
All these are fixed in 0.2.1.
I also noticed that the 'Use all mine' option in the resolver used all the local lines to resolve conflicts, but it left all the non-conflicting merges in place. I don't think this is right, but I can't fix it today.
Next up is resolving name changes and moves, and the auto-resolve options. Then, hopefully, independent merge in to a third file/location and changeset rollback.
Sunday, 24 February 2008
One spanking new merge/conflict resolution tool! Colours are a little toned down a bit since the prototype (below), but it took a while to get from prototype to production code, mainly due to the number of scenarios involved. I wanted the merge output window to show exactly what would be written out/saved, so where lines are removed these are shown only in the margins. The lines above and below the 'missing' section right-click to give 'redo above' or 'undo-merge below' options. Some lines can have both above and below options which can be for undo/redo merges or undo resolution.
Hopefully the system should be fairly intuitive to use and should be much better than the MS DiffMerge tool.
Two diff views, diff view and merge/conflict view.
Diff view shows differences base:server (theirs) on the left and base:local (yours) on the right. Blank lines are used to keep the files in sync. In merge/conflict view all conflict areas are highlighted and all changes base:server that can/will be merged are shown merged into the right hand base:local view. Clicking between them and looking at the results is proably the best way to get a feel for this.
Quite often there are long sections of code with no changes/conflicts, you can choose not to see them by choosing how many context lines around changes/conflicts to show
Arrange the two diff views and output windows all side-by-side (good for wide screen monitors), diffs together, output beneath (like the MS DiffMerge tool), or my favorite, diffs side-by-side and output in a different window (great for twin monitor set ups)
Don't know what all the colours mean? Hover over any coloured section and help text will explain what the section is showing.
Also new in this release a new history browser:
History on the left, full details of check-in on the right. Clink file on right to see history of that, use back button to return, or up-level button for folder history. Right click one or two versions for diff options.
Fed up with the 'Binary Files Differ' response when diffing dlls? Not with LizardTF:
(test data a little suspect, but trying to diff dlls or exes will give this screen to compare version stamps, etc)
Text diffs are like this:
(note line differnces shown beneath)
(inline diff, only three context lines).
Note the left and right folder/repo/version browse buttons. once a diff is in view you can reload either side from any file or repository item. If a repository item is loaded you can choose any historic version.
All version picker combo boxes have a 'browse' item, when selected this launches the history browser (shown above) to help you pick the right version.
Also from the explorer context menu:
Blame (anotate) shows originating changeset id/author for all lines in a source file.
Check out/lock, allows locking
Lizard Review, shows all conflicts, out-of-dates, pending changes and other checkouts for selected path
Get specific version - version combo for 'Get' option now works!
Create Workspace option asks if you want to get latest for new workspace and scans/builds Lizard meta data.
Soon I am going to have to write a manual.
Sunday, 17 February 2008
I have now fixed the folder scanning to get the folder statuses right, which was bugging me
You can now set the lock level on (or after) check out.
There is a 'review' option which shows all conflicts, out of dates and pending changes by default.
All review options support viewing of explorer file properties from review screen
Context menu Diffs are all in place for review and history screens for working base, server latest and previous versions (all other versions can be browsed to/selected from diff window).
All version combo's support version browsing through bespoke history/detail screen.
LizardTF has it's own history display, which has integrated history panel. This also supports browsing.
The conflict resolver is nearly finished! supports resolving conflicts, undo-ing non-conflicted merges, redo-ing any merges that you have undone. Just undo-ing resolutions left to do! Hoorah!
This turned out to be rather fiddly with the undo/redo options, mainly when an operation removes all lines, and you have to mark above and below to show that something happened that can be undone, and some lines can have one operation done above, and a different one below.
To late tonight but a new release will be posted this week.
Thursday, 31 January 2008
Zoom forward a year and a bit, I use TFS at work now, I hate the Microsoft merge tool, so I'm writing a fresh one. I've got the two-way diffs all sorted (should be released this weekend) and I'm feeling all cocky, I can read the diff3 output, and I'm ready to go...
So you've got add, deletes and changes, easy. You have changes which are the same in both server and local files, you don't have to anything with these, easy. You have changes only on the server, these can merge straight into the local target, still easy. You have different changes to server and local, mark it up as a conflict, still pretty easy. These conflicts can be any of the three types on either side. Arrrggghhh! How many variations of add, deletes and changes do you end up with? Loads. How many colours do you need to clearly identify them all? Too many!
Here is the V0.1 LizardTF 3-way-diff visualiser. Base/Server changes shown inline on the left, Base/Local changes shown inline on right. Green for inserts, Blue for changes, Red for deletions, pale shades where the same change has already been made to both server and local. Mid colours for changes on the server which are mergeable (no change on local/local matches bases), and dark colours with yellow text and square glyphs for your actual, needs intervention, conflicts. Plus the usual mark up of base/local changes*.
So there you go. No wonder TortoiseSVN was rather colourful.
Scintilla also offers quite nice TipText, so hovering over a marked area will display a pop-up text describing the meaning of the colours. (not shown).
*Only if the local target shares the base with the server. With LizardTF it will be possible to merge changesets/diffs into any target irrespective of origin.
Sunday, 20 January 2008
- Side-by-side or Inline diff views
- Line to line diff shown at bottom for side-by-side view
- Can show any number of context lines in Inline view
- File browser to load alternative right/left files
- Repository browser to load alternative repository files
- Version combos to quickly change which versions you are comparing
- Instance switch to Blame view for either right or left hand side
- Blame shows originating changesets and author for each line and uncommitted local changes if ran for local file. (can also be ran for any repository version)
- All line differences marked in main view
- Find functions - quick find and a more featured find
- Context line options for Side-by-side view
- Click on Blame line/changeset id number to show diff to that version
- Click on Blame line/changeset id to get full description of changeset
- Switch for visible whitespace
Inline, showing only 5 context lines.
Sunday, 13 January 2008
The sourceforge project is still there, but I'll be wrapping it up some time soon.
This blog will be the main place for news on releases.
I've been thinking about conflict resolution, and the ability to merge a changeset into another folder, when they are not TF branches. TortoiseSVN allows this by using GNU Diff and Patch. I'm not that fond of MS TFS DiffMerge program for resolving conflicts and it *always* assumes both sides have a common ancestor. While you could use this for applying a changeset to a new location the fact that it's default output when a conflict is found is to use the base version (rather than the local) is a bit off putting as it makes no sense in this context.
I really didn't want to write a diff/merge tool myself as I figured it would take a long time and there were already so many out there.... however, I couldn't find one that behaved quite how I wanted and one thing led to another.
A diff/merge program has two hard bits and some glue. The hard bits are working out the differences and displaying them. I've used GNU Diff for the first and Scintilla + ScintillaNET for the second. Even with these doing the hard bits I was surprised how quickly it all came together.
I've used Diff many times before and the output is pretty easy to read/parse. I've read about Scintilla, and looked at it briefly before. It is a very comprehensive text editing/rendering component. Many open source text editors use it, as does TortoiseSVN, so it was a fairly obvious, if a little daunting choice. Then I found ScintillaNET and it became a lot less daunting.
The end result, a side-by-side two-way difference display, showing changes, insertions and deletions, an in-line version that does the same, but can be told to show only changes and an optional number of context lines, and ... (small fanfare please) LizardBlame.
Named after TortoiseBlame, this shows where every line of code came from and who put it there. I use to use TortoiseSVN/SVN a lot in a big co-located dev. environment, and this tool was incredibly useful. How many times have you worked on code and seen lines of code that seem so hopelessly wrong and yet somehow vital? With Blame you can quickly see what changeset it came from, and (if you use tickets/work items) find out what piece of work the changeset belonged to. This can be far more useful than most comments.
These are all functionally complete, and just need toolbars, find, next/previous, etc etc options.
The three-way diffs/merging and conflict resolution are to follow, but using Diff3 and Scintilla again, this shouldn't be too bad. A big thanks to GNU, Chris Rickard for his ScintillaNET and the numerous folk behind the Scintilla and GNU projects.
Inline Diff showing before and after in one document
Side-by-Side Diff for easy comparision
LizardBlame, showing the originating changeset and author for each line.
As you can see, there are no bells, no whistles, no toolbars and no options yet. I intend to include a line-to-line comparison underneath for spotting those pesky single charactor/one piece of white space changes; to be able to show multiple files (a whole changeset) one after the other in inline-mode for easy review of whole changesets (pending or existing); and the usual next/previous change navigation and find functions.
If anyone has any other features they think are missing from other Diff tools, please let me know.
I've not had a chance to release any source/install for this yet.
Tuesday, 8 January 2008
If you are writting shell extention context menus you will use the IContextMenu interface. MSDN says:
'InvokeCommand returns S_OK if the command was successfully invoked or an appropriate error message if it was not.'
What is does not say is that if your implementation of InvokeCommand is not handling the particular menu item requested it MUST return E_FAIL (0x80004005) otherwise further menu item handling is not called.
Many thanks to Dan Brewer from Extensis for his help with this
Monday, 7 January 2008
Review Form For Checkins/Undos/Gets
Hierarchical diff tool can diff between file system folders and/or
any branch/version repository folders.
It's hosted here: https://sourceforge.net/projects/lizardtf/
I'll shut up about it now.