For any given folder I need to get a file history and determine if there have been any check-ins made since date X. Since our server is version 1.2 and is only a few months old I would appreciate any solution that didn't involve the word "upgrade"!
First I looked at the command-line client. It has a 'history' option there and seems to be just what I need. So I run a test query and immediately hit problem #1 :
Problem #1: History command returns invalid XML
The XML returned for the 'history' command is often incorrectly formed owing to the presence of XML format characters such as '<' and '>' in the check-in comments. As a former XML nerd I know that the server should be putting user-defined content (and anything else which can legally include format characters) in CDATA sections, alternatively they should escape the format characters to >, < etc.
Since MSXML refuses to load invalid XML the history command is useless to me until I write my own XML parser that can handle the malformed responses. I was thinking about the best way to do this and running a history command several times in a row when I noticed problem #2 :
Problem #2: History is incomplete and randomly ordered
I can run the history command any number of times in rapid succession and never get the same result twice. Each run gives me a randomly-ordered randomly-chosen subset of the full history!
Problem #3: Vault 1.x and Vault 2.x seem utterly incompatible
With the above problems in mind I googled up these forums and found an apparent solution in a seperate thread... some kind soul had posted source code for something that seemed to do just what I want! So I download the .NET code... oh dear I need Vault client 2.0 to do that simple thing. Can 2.0 servers really not handle 1.x clients? Never mind... I install the 2.0 client and download the code.
I compile it successfully and run it to grab what will hopefully be a correctly-formed and ordered history from my server... and it bombs out because a 2.0 client can't talk to a 1.x server either! Does backwards-compatibility mean nothing to you people?! For extra annoyance I let the 2.0 client install do it's default thing of overwriting my 1.x install, something which strongly suggests it should be able to handle 1.x servers, but now I can't use Vault at all until I reinstall 1.x.
So I'm near the end of my tether ... what do I have to do to get a full and valid file/project history?
Thanks for any suggestions!
File history
Moderator: SourceGear
Sorry about the version incompatibilities.
The easiest way to get this info is by using the GUI client, which has a large number of query criteria and sort fields (available in both 1.2 and 2.0).
If you need to use the Command Line client, unfortunately, the easiest thing to do is upgrade everyone to 2.0.3, where we just added the ability for the CLC to query by date and to sort.
If you need to stay on 1.2, you could look at the source code of the 2.0 CLC, and apply the changes to 1.2 CLC code to get up and running. It is available in the Client API installer on our Vault downloads page on the main web site.
The easiest way to get this info is by using the GUI client, which has a large number of query criteria and sort fields (available in both 1.2 and 2.0).
If you need to use the Command Line client, unfortunately, the easiest thing to do is upgrade everyone to 2.0.3, where we just added the ability for the CLC to query by date and to sort.
If you need to stay on 1.2, you could look at the source code of the 2.0 CLC, and apply the changes to 1.2 CLC code to get up and running. It is available in the Client API installer on our Vault downloads page on the main web site.
Looking at the sample history query posted at:
http://support.sourcegear.com/viewtopic.php?t=450
When I loaded up the solution, I had to fix the references that had exclamation points (just point them to the dlls in c:\program files\sourcegear\vault client)
Then delete the sections dealing with snapshot, since that didn't exist in 1.x.
Now, modify the req.BeginDate to be the date that you want to query for.
That should get you querying history in 1.x for exactly the information that you want. Post here again if you have any more questions.
-jeremy
http://support.sourcegear.com/viewtopic.php?t=450
When I loaded up the solution, I had to fix the references that had exclamation points (just point them to the dlls in c:\program files\sourcegear\vault client)
Then delete the sections dealing with snapshot, since that didn't exist in 1.x.
Now, modify the req.BeginDate to be the date that you want to query for.
That should get you querying history in 1.x for exactly the information that you want. Post here again if you have any more questions.
-jeremy
Ok, I modified the 2.0 cmd client code and have got a history request running on 1.2... yay!
Only it seems to ignore the VaultHistoryQueryRequest.BeginDate property - it seems to return the first 1000 items regardless of date... boo!
Maybe I need to poke the DateFilterMask and/or DateFilterType properties? But I can't find any documentation... boo!
How do you use these properties?
Only it seems to ignore the VaultHistoryQueryRequest.BeginDate property - it seems to return the first 1000 items regardless of date... boo!
Maybe I need to poke the DateFilterMask and/or DateFilterType properties? But I can't find any documentation... boo!
How do you use these properties?
Since posting the post immediately above (where I forgot to log in) I figured out that I have to set both BeginDate and EndDate for the date filter to work.
I now have a working utility! It's interesting to single-step in the debugger and see what calls take up the time... I assumed it was the query that took the bulk of the time, but it seems to be mostly login! Is there anything I can do to speed up login time?
And I have noticed that setting a datetime range of 1 day or less results in an invalid range exception. I can work around this by expanding to 2 days and filtering out the older ones, but that kind of defeats the point of having filtering on the server in the first place.
I now have a working utility! It's interesting to single-step in the debugger and see what calls take up the time... I assumed it was the query that took the bulk of the time, but it seems to be mostly login! Is there anything I can do to speed up login time?
And I have noticed that setting a datetime range of 1 day or less results in an invalid range exception. I can work around this by expanding to 2 days and filtering out the older ones, but that kind of defeats the point of having filtering on the server in the first place.
Reuben:
a)
Here is a code snippet from Vault 2.0.3's CLC. I believe this should compile w/ the 1.2.3 client, so let me know if there is a problem.
I'm hoping this example helps in modifying your custom client.
b)
If you want to limit the output of a history query, set the hq.RowLimit to a positive integer value.
c)
Vault has greatly improved when comparing 1.2.3 vs. 2.0.x. You've mentioned you cannot upgrade to Vault 2.x. If it is not too bold or intrusive, may I ask why? Is it a matter of timing? Is it a matter of stability to some internal process?
a)
Here is a code snippet from Vault 2.0.3's CLC. I believe this should compile w/ the 1.2.3 client, so let me know if there is a problem.
I'm hoping this example helps in modifying your custom client.
Code: Select all
VaultHistoryQueryRequest hq = new VaultHistoryQueryRequest();
DateTime dtBegin = <SOME_DATE> | VaultDate.EmptyDate();
DateTime dtEnd = <SOME_DATE> | VaultDate.EmptyDate();
bool bBegDateNull = VaultDate.IsEmptyDate(dtBegin);
bool bEndDateNull = VaultDate.IsEmptyDate(dtEnd);
if ( (bBegDateNull == true) && (bEndDateNull == true) )
{
// no date range
hq.DateFilterMask = VaultQueryRequestDates.DoNotFilter;
hq.BeginDate = hq.EndDate = VaultDate.EmptyDate();
}
else if ( (bBegDateNull == false) && (bEndDateNull == false) )
{
// a range of dates has been requested
hq.DateFilterMask = VaultQueryRequestDates.HistoryBefore | VaultQueryRequestDates.HistoryAfter;
hq.BeginDate = dtBegin;
hq.EndDate = dtEnd;
}
else if (bBegDateNull == false)
{
// when dtBegin (floor) has been specified,
// and dtEnd has not, the user
// is asking for all dates after the date.
// a query of this type should be defined so the
// end date is valid and the begindate is empty.
hq.DateFilterMask = VaultQueryRequestDates.HistoryAfter;
hq.BeginDate = VaultDate.EmptyDate();
hq.EndDate = dtBegin;
}
else // bEndDateNull will be false
{
// when dtEnd (ceiling) has been specified,
// and dtBegin has not, the user
// is asking for all dates before the date.
// a query of this type should be defined so the
// begin date is valid and the enddate is empty.
hq.DateFilterMask = VaultQueryRequestDates.HistoryBefore;
hq.BeginDate = dtEnd;
hq.EndDate = VaultDate.EmptyDate();
}
b)
If you want to limit the output of a history query, set the hq.RowLimit to a positive integer value.
c)
Vault has greatly improved when comparing 1.2.3 vs. 2.0.x. You've mentioned you cannot upgrade to Vault 2.x. If it is not too bold or intrusive, may I ask why? Is it a matter of timing? Is it a matter of stability to some internal process?
Jeff Clausius
SourceGear
SourceGear