Version control in MorphX

Thank you for the sneak peak!  And thank you for the Team Foundation Server support!

Can you elaborate on the concurrent checkouts (particularly merging check-ins).

Also, can the "Change List" be identified later on the Team Foundation Server side so the change set can be fetched for deployment or building on a test server?

The biggest problem we've had with using version control is that it provides absolutely no help in deploying our changes in a controlled manner. 

For example, we make a new project for each Change Request we get from our users.  From the VCS side it is impossible to identify which XPO files belong to an AX project.  We also haven't found a good way to identify which versions of objects have been deployed to our test and production systems, and which versions in VCS have been tested and marked as "approved" for deployment.

If you look at an object in the AOT of your production AOS, is there anything that identifies the version # from the VCS that was deployed?  I'd like to be able to look at an object in production and see that it corresponds to version "n" in our VCS.

And would you guys PLEASE consider using GUIDs for object IDs and ditching the "Team Server" entirely?  It makes development very difficult when we have partners and remote developers who don't want to be VPN'd to our network just so they can be connected to the team server.

You are very welcome.

With regards to multiple check-out nothing new is added in 5.0. VSS in 4.0 already supports this, if you enable it in the VSS Admin tool. The way it works is that the version control backend will automatically attempt to merge the files. In most cases it succeeds and both check-ins succeed. In cases where the exact same lines has been modified the last check-in is rejected. The developer then has to resolve the conflict manually, and check-in again.

Keeping track of versions across installation can be difficult. Even more so if you use XPO files as a way of deploying. I strongly recommend only using AOD files. In combination with a VCS it requires a build step. In the next update of the documentation on MSDN we will release a documentation on how to setup an automated build procedure. Using an AOD file you can stamp each version with a build number, and you can label (VSS term) your VCS files with the build number. Then you know what you got at all times, in every environment.

Regarding IDs, *sigh*, we know. What I can promise is we will address this in the very near future after 5.0. If we don't Microsoft will be out-of-IDs very shortly.  If the solution will be GUID based or not is still not decided. The other obvious alternative is NAME based - like .NET and C#.

This is truly a powerful feature and has been needed for a long time. It will definitely be very useful to solution development in Dynamics AX but also for implementation projects and make it much more easy to maintain the customized customer applications. At least as I see it. 

However I’m curious to know if the MorphX VCS functionality is all together hidden inside the kernel or if it will be possible to hook in to these VCS events (like check-out/in etc.)?

The version control system can be fully controlled from X++. In fact the kernel has no knowledge about which provider is used (VSS, TFS or MorphX).

In the AOT you will find the VersionControl class, it has methods like checkin, checkout, undoCheckout. These can be customized like you normally do in MorphX.

The documentation for this class on MSDN will (eventually) be available here:
http://msdn2.microsoft.com/en-us/library/aa843010.aspx

Hi there

Hope you are still watchin this blog.

Good news about a build-in VCS - it seems like the right configuration for my company - except for one thing !

It seems that version control on each object is optional - you have to manually enable it - per object !

I would like to have version control enforced - period - so that no developer can edit anything in the AOT, without a trace to who did the change, and when.

Is this possible ??