using the api to track all changes and other stuff

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
grif
Posts: 8
Joined: Wed Feb 11, 2004 4:33 pm

using the api to track all changes and other stuff

Post by grif » Thu Feb 12, 2004 5:06 pm

I have a couple questions regarding the API that I'm hoping someone can give me some direction on.
First, I see in the .chm, the ClientInstance class overview indicates that it "encapsulates one vault server connection." What I would really like to do is be able to have a service running that would capture all check-ins, adds, deletes, etc. and aggregate those up somewhere. I've seen the example using the rss2.aspx to get the history, but what I was thinking would be a little more real-time. Can I use the VaultClientPresentationLib to do something like that? Or is there another library/method I could use to connect with the Vault server and from there receive events when things occur?
Next, I was hoping that I could receive some clarification on the history method that is used in the command-line sample. There is a "type" attribute that is returned. Is there a decoder-ring available that will tell me what the type value represents, or will I just need to create all of the different operations and figure it out on my own? Either way its cool and I'm warming up to your API. I found it frustrating at first, but I feel like I am starting to make some progress.
Is there a way to put a label on a single file - not on a folder? I believe this was available through the SS api, but not through the UI so I am wondering if that same functionality may be available here.
Finally, I have read on your site and on some others about the upcoming release of Vault 2.0. While I understand that the API isn't officially "supported", are there going to be any backwards compatibility issues when 2.0 is available (that you know about) ? Surely, it would stink to get everything that we want to do accomplished with the API and version 1.2.3, then apply the new version and things aren't working any longer - but then again, such is the life of a software developer. :wink:
Any other information about other changes related to the API in 2.0 would be exciting to know as well.

Thanks for your time.
grif

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Re: using the api to track all changes and other stuff

Post by ericsink » Fri Feb 13, 2004 7:00 am

grif wrote:First, I see in the .chm, the ClientInstance class overview indicates that it "encapsulates one vault server connection." What I would really like to do is be able to have a service running that would capture all check-ins, adds, deletes, etc. and aggregate those up somewhere. I've seen the example using the rss2.aspx to get the history, but what I was thinking would be a little more real-time.
ClientInstance can be used for this problem, although I'm not sure what you mean by "a little more real-time". You will have to poll for changes at some interval.
Can I use the VaultClientPresentationLib to do something like that?
No. PresentationLib is not intended to be used outside of SourceGear. It's all GUI stuff anyway.
Or is there another library/method I could use to connect with the Vault server and from there receive events when things occur?
Ah, I think I see what you want. Sorry, you can't have it. :D

Actually, Vault 2.0 does contain a sort of a plugin mechanism for notifying outside apps of changes to the repository. I don't know much about it. I suspect we're not ready to help anybody else use it yet, but we'll need to clarify that.
Next, I was hoping that I could receive some clarification on the history method that is used in the command-line sample. There is a "type" attribute that is returned. Is there a decoder-ring available that will tell me what the type value represents, or will I just need to create all of the different operations and figure it out on my own?
There is a decoder ring:

Code: Select all

public class VaultHistoryType
{
public const byte Added                 = 10;
public const byte BranchedFrom          = 20;
public const byte BranchedFromItem      = 30;
public const byte BranchedFromShare     = 40;
public const byte BranchedFromShareItem = 50;
public const byte CheckIn               = 60;
public const byte Created               = 70;
public const byte Deleted               = 80;
public const byte Label                 = 90;
public const byte MovedFrom             = 120;
public const byte MovedTo               = 130;
public const byte Obliterated           = 140;
public const byte Pinned                = 150;
public const byte PropertyChange        = 160;
public const byte Renamed               = 170;
public const byte RenamedItem           = 180;
public const byte SharedTo              = 190;
public const byte Snapshot              = 200;
public const byte SnapshotFrom          = 201;
public const byte SnapshotItem          = 202;
public const byte Undeleted             = 210;
public const byte UnPinned              = 220;
public const byte Rollback              = 230;
}
Is there a way to put a label on a single file - not on a folder? I believe this was available through the SS api, but not through the UI so I am wondering if that same functionality may be available here.
Labels are entirely different in 2.0. There is a way to put a label on a single file. I believe the new client API installer will come with the source code to the new command line client which will serve as a new sample for the updated API.
Finally, I have read on your site and on some others about the upcoming release of Vault 2.0. While I understand that the API isn't officially "supported", are there going to be any backwards compatibility issues when 2.0 is available (that you know about) ?
Yes, there will be backwards compatibility issues. The API isn't changing dramatically, but probably just enough to break your app. :D
Surely, it would stink to get everything that we want to do accomplished with the API and version 1.2.3, then apply the new version and things aren't working any longer - but then again, such is the life of a software developer. :wink:

The changes shouldn't be too bad.
Any other information about other changes related to the API in 2.0 would be exciting to know as well.
Like I said above, the best starting point for the 2.0 API will be the new command line client source code.

The 2.0 release will be out very soon. It will be easier to answer questions about its API after it is actually available.
Eric Sink
Software Craftsman
SourceGear

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Sat Feb 14, 2004 2:46 pm

a little more info....

here is an excerpt from the vault server sql ddl, and a small description for each history enumeration:


--****** object: user Defined datatype uhistorytype Script date: 7/8/2002 9:43:13 AM ******--
-- ENUM
-- Added = 10; // Added (on the parent folder for the created item)
-- BranchedFrom = 20; // Branched From sub item (on the parent folder the item was branched into)
-- BranchedFromItem = 30; // Branched from sub item (on the item itself - copy branch)
-- BranchedFromShare = 40; // Shared Branch from sub item (on the parent folder the share was branched from)
-- BranchedFromShareItem = 50; // Shared Branch from sub item (on the item itself - share branch)
-- CheckIn = 60; // CheckIn
-- Created = 70; // Created (on the file or folder)
-- Deleted = 80; // Deleted (on the parent folder for the deleted item)
-- Label = 90; // applied label

-- MovedFrom = 120; // Moved From (on the parent folder the item was just moved into)
-- MovedTo = 130; // Moved To (on the parent folder the item was moved out of)
-- Obliterated = 140; // Obliterated (on the parent folder for the obliterated item)
-- Pinned = 150; // Pinned (on the parent folder for the pinned item)
-- PropertyChange = 160; // Property Change
-- Renamed = 170; // Renamed (on the file or folder)
-- RenamedItem = 180; // Renamed Item (on the parent folder of the item renamed)
-- SharedTo = 190; // Shared To
-- Snapshot = 200; // history item on the item snapshotted
-- SnapshotFrom = 201; // history item on the destination folder of the snapshot
-- SnapshotItem = 202; // history for the creation
-- Undeleted = 210; // Undeleted (on the parent folder for the undeleted item)
-- UnPinned = 220; // UnPinned (on the parent folder for the unpinned item)
-- Rollback = 230; // Rollback
Jeff Clausius
SourceGear

bmschkerke
Posts: 11
Joined: Mon Feb 16, 2004 8:53 am

Er, I did this, sort of...

Post by bmschkerke » Mon Feb 16, 2004 9:07 am

.
Last edited by bmschkerke on Tue May 14, 2013 2:21 pm, edited 1 time in total.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Mar 12, 2004 7:05 pm

I wrote up a sample history query with the Client API. You can find it at:
http://support.sourcegear.com/viewtopic.php?t=450

Post Reply