rasane:
I have sent you the package as requested; let me know if you have any
issues.
Re: different versions of the Vault Package, its important to
distinguish between a breaking change between vault releases that are
due to an actual Vault API change and ones that are merely due to DLL
versioning and/or Vault Server protocol versioning.
Breaking changes between Vault 3.5.x and Vault 4.x are indeed due to
breaking API changes introduced by SourceGear; as Vault (the product)
gets more features, the corresponding Vault API changes as well so
when Vault went from 3.5.x to 4.x it was necessary to change some of
the NAnt-related scripting in the corresponding CI-F package to
accomodate this. Its true that once this was done, there was no way
to use this package for Vault 3.5.x any longer so this was indeed a
'no looking back' update to the package.
However, subsequent changes in Vault version within the major rev
number (e.g., from Vault 4.0 to 4.0.2 to 4.1 and now to 4.1.1) do not
introduce breaking changes via the Vault NAnt API (I imagine they
*could* but SourceGear explicitly tries not to within a major rev
number). These changes are all about the DLL versions of the
SourceGear API libraries and the corresponding protocol version of the
Vault Server. In these cases, the SAME rules apply as apply for the
SourceGear Vault Windows Client app itself: GENERALLY so long as the
major rev number is the same, any Vault Client can connect to any
Vault Server that is running a version equal to or lesser than the
client app (so a 4.0.2 client can connect to a 4.0 server but NOT the
other way around). You can see this yourself if/when you would
connect to a 4.0 server with a 4.0.2 client and the client will say
something along the lines of "the server and client protocol versions
don't match; SourceGear recommends strongly that the server and client
run the same version for maximum compatibility". And if you do the
reverse (connect a 4.0 client to a 4.0.2 server) you get an ERROR
dialog along the lines of "server is running an incompatible protocol
version".
This is all due to the fact that Vault is really nothing but a giant
collection of ASP.NET ASMX webservices that front-end a SQL server
database; since the client and the webservices need to exchange data
via proxy classes that are version-matched, you run into this problem
(which is a general issue with any web-service-based approach to
things that relies on ASMX-generated proxy classes instead of more
neutral WSDL, etc. to describe the 'contract' level stuff going on
(please nobody flame me on the pro- or anti-WSDL thoughts, I don't
care for your opinion here).
Given all this, GENERALLY within a single major Vault rev number (4 in
this example), the only changes that anyone would need to make to the
Vault Package for CI-F would be to replace the DLL files in the ...
\Packages\Vault\bin\ folder with the proper corresponding version that
match your Vault deployment. For example, if you have gone to 4.1.1
(and this package I just sent you does not yet since I haven't
bothered to deploy that for ourselves yet), you will DEFINITELY need
to update all the DLL files in the \Packages\Vault\Bin\ folder else
you will indeed run into the exact same version issues that I just
described above.
I think that your suggesting about separate packages in CI-F for
different Vault versions is not a bad idea re: versions with actual
breaking API changes, but to keep a separate package in CI-F for each
and every point-release of Vault so that these DLL-only versioning
issues are mitigated would be really challenging in my mind -- we
would have a ....
3.5 package
3.5.1 package
4.0 package
4.0.2 package
4.1 package
4.1.1 package
etc, etc, etc.
...which quickly gets a bit on the crazy side. I think that until you
mentioned this issue, I really just figured that pretty much everyone
would be on Vault's subscrption/upg plan (and thus running the near-
latest release) since SCC is really so central a need for a dev team
that everyone would be hell-bent on keeping their installations
current.
I hope this helps clear this up a little and gives you some guidance
on how to proceed.
Note that for explicit guidance on which Vault version updates do and
do not REQUIRE you to change your Vault Client (and thus the libraries
in the Vault CI-F package) you should always refer to the release
notes provided by SourceGear for the Vault updates; when they
introduce a breaking protocol change, they tend to indicate such in
their release notes.
-Steve B.
On Apr 8, 7:18 pm, rasane <sras...@gmail.com> wrote:
> Hi Steve,
> Thanks again. I have emailed you and please send the CI Factory
> package contents as you mention... (please provide steps)
> Another item, could Jay please upgrade to the latest version of vault
> released last week - 4.1.1 - I hope there are no breaking changes with
> vault in this release, but this is the one we have taken up.
> Is there a way for you to maintain vault folders with release, since
> there are breaking changes? we would be glad to use the latest, but
> there would be some who cannot really afford to upgrade (just like our
> case when I started this thread)!!
> Regards,
> rasane