Nant task - Checkin, get new folder version back?

[ajj3085]

Hi,

I'm checking in some files at the end of a successful build. I'd like to label that so that I can grab that version more easily if I want to deploy it. I can label right after the checkin, but it's possible that another checkin happens between the scripts checkin and label.

Is it possible to get the new folder version which was incremented due to the checkin? Also, is there any way to label a specific folder version? I know it can be done in the gui client, but doesn't seem possible with the nant tasks.

Thanks
Andy

ps - are all posting here going through moderation? I don't recall that happening until the past few weeks.

[jclausius]

Andy,

What if you used the vaulthistory task, with a row limit of 1 on the folder? Assuming you know no one committed a change set between the build's GET but before committing your changes from the build, you could apply the label to that version of the folder. The key is knowing the folder version of the GET, and the folder version after committing your change set. If the folder's version changed, then someone committed a change set between the two. Not sure what you would do in that case.

What if you committed, got the version of the folder right after the commit, and then labeled that version? That way you know w/ out a doubt every line of code that goes into any kind of build.

[lbauer]

ps - are all posting here going through moderation? I don't recall that happening until the past few weeks.

New forum users always go through moderation, but we've noticed that some long time users are being flagged for moderation, too. We're not sure why, but we're investigating.

[lbauer]

Andy -- regarding your posts which have been flagged for moderation:

Have you tried logging out of the forum and then logging in again? I wonder if that would help.

[ajj3085]

[quote="jclausius"]What if you used the vaulthistory task, with a row limit of 1 on the folder? Assuming you know no one committed a change set between the build's GET but before committing your changes from the build, you could apply the label to that version of the folder. The key is knowing the folder version of the GET, and the folder version after committing your change set. If the folder's version changed, then someone committed a change set between the two. Not sure what you would do in that case.

What if you committed, got the version of the folder right after the commit, and then labeled that version? That way you know w/ out a doubt every line of code that goes into any kind of build.[/quote]

Jeff,

Thanks for the suggestions. I had thought about the latter option, but I had thought there's still a possiblity that a commit occures between the build's commit and it's label. That may or may not be likely depending on how Vault handles two commits at once (that is, the build begins it's commit, and while that's working another commit begins and completes before the first ends).

[ajj3085]

[quote="lbauer"]Andy -- regarding your posts which have been flagged for moderation:

Have you tried logging out of the forum and then logging in again? I wonder if that would help.[/quote]

No joy. I logged off, and when i tried to log back on it immediately said I failed too many login attempts (odd since I had just logged off) and wanted me to to do a captcha as well as logon.

[jclausius]

Thanks for the suggestions. I had thought about the latter option, but I had thought there's still a possiblity that a commit occures between the build's commit and it's label. That may or may not be likely depending on how Vault handles two commits at once (that is, the build begins it's commit, and while that's working another commit begins and completes before the first ends).

It all depends on which one gets there first. Transactions will be atomic, so the 1st one to ask the server to End the transaction will be granted a synchronization lock. The other transaction is blocked on that repository until the transaction ends. After the transaction has been successfully saved, the lock is released and the 2nd tx can then proceed.

[ajj3085]

[quote="jclausius"]It all depends on which one gets there first. Transactions will be atomic, so the 1st one to ask the server to End the transaction will be granted a synchronization lock. The other transaction is blocked on that repository until the transaction ends. After the transaction has been successfully saved, the lock is released and the 2nd tx can then proceed.[/quote]

What's what I thought. Could a feature request be added so that the last part of committing the transaction gets the new folder version back? When you commit in SVN the last thing it displays was the revision number you just created. The version of the folder to which you committed should work fine (ie, if you commit to $/project/myfolder you get back the folder version for $/project/myfolder).

Thanks
Andy

[jclausius]

At what level are you using the API? In other words, are you using, VaultClientIntegrationLib, the lower libraries, or NAnt Tasks?

Right now, from the pure API, EndTx() will return the latest repository revision, plus it will return the *new* version of each item within the change set within the VaultRequestItem. That should give you enough info to create the label, but are you seeing that data?

[ajj3085]

[quote="jclausius"]At what level are you using the API? In other words, are you using, VaultClientIntegrationLib, the lower libraries, or NAnt Tasks?[/quote]

I'm using the Nant tasks (which I ported to Msbuild).

[jclausius]

Andy,

Yeah, the NAnt tasks do not provide you with enough data to get what you're looking for. There's not a way to return a folder version as you could have a change set with files from folders all over the repository.

In any case, I'll log a request to see if there is a way the commit NAnt task could return folder version information from all folders in the "just committed" change set.

[ajj3085]

[quote="jclausius"]Yeah, the NAnt tasks do not provide you with enough data to get what you're looking for. There's not a way to return a folder version as you could have a change set with files from folders all over the repository.

In any case, I'll log a request to see if there is a way the commit NAnt task could return folder version information from all folders in the "just committed" change set.[/quote]

I understand what you're saying, and I appreciate you looking into this for me.

If it helps, when I do the check in it's always for $/project/trunk (or $/project/branches/branch), so it's just a single folder. Never $/project1/trunk;$/project2/trunk. Is the latter a common use case?

[jclausius]

... $/project1/trunk;$/project2/trunk. Is the latter a common use case?

It can be. It really all depends on the type of user and their process.

The Vault UI is extremely flexible in that you can operate in multiple folders in this regard.