Corey.Caldwell Posted January 23, 2012 Report Share Posted January 23, 2012 I apologize if this has been covered elsewhere but there was only one other thread with xlinks and it didn't seem to fit my situation. I'm testing out Plastic 4 and I've got some common code that I want to be shared across several projects. My setup is: CommonProject WebApp1 (cm xlink -w ..\WebApp1\CommonProject / cs:1@CommonProject@[server]:[Port]) WebApp2 (cm xlink -w ..\WebApp2\CommonProject / cs:1@CommonProject@[server]:[Port]) I've added xlinks from WebApp1 -> CommonProject and WebApp2 -> CommonProject. As I work in WebApp1's Common area, i can see my changes both in WebApp1's changesets/branches as well CommonProject's changesets/branches. What I don't see is these changes ending up in my WebApp2 workspace. Furthermore, when I make a change right in CommonProject, I don't see these changes in either WebApp. I've used update/update forces both on the whole workspace as well as the CommonProject folder under my WebApp1 and WebApp2 workspaces but never see the changed propagate up. If xlinks doesn't currently support this, how can I set up my workspaces to work in this way? Using the following selector didn't seem to work: repository "CommonProject@[server]:[Port]" mount "/CommonProject/" path "/" br "/main/dev" co "/main/dev" repository "WebApp1@[server]:[Port]" path "/" smartbranch "/main/dev" Link to comment Share on other sites More sharing options...
manu Posted January 24, 2012 Report Share Posted January 24, 2012 Hi Corey, What I don't see is these changes ending up in my WebApp2 workspace. Furthermore, when I make a change right in CommonProject, I don't see these changes in either WebApp. I've used update/update forces both on the whole workspace as well as the CommonProject folder under my WebApp1 and WebApp2 workspaces but never see the changed propagate up. The Xlink is only going to propagate the changes if you work in this way: WebApp1 (cm xlink -w ..\WebApp1\CommonProject / cs:1@CommonProject@[server]:[Port]) I make a new branch "task001" in "WebApp1" repository, then I switch to it and I make some changes under the Xlink directory, finally I commit the changes. XlinkAutoAction: A new branch called "task001" on repository "CommonProject" is going to be created from the changeset 1, at the checkin time the changes under the Xlink are going to be placed in this new "CommonProject" 'task001' branch, the Xlink target changeset at the "WebApp1" repository is going to be updated to the new changeset created in the branch "task001" at the "CommonProject" repository. I switch my workspace to the "WebApp1" main branch and I commit the merge result. XlinkAutoAction: The "task001" branch at "CommonProject" repository and the "task001" branch at "WebApp1" repository are going to be merged into "CommonProject" and "WebApp1" repositories. When the checkin is performed a new merge result changeset is created in the "CommonProject" main branch, and also a new merge result changeset will be created on the "WebApp1" repository main branch with the Xlink updated to the "CommonRepository" merge result changeset. If you are working out of this workflow the Xlink will be outdated and you will have to edit the Xlink by hand (-e option in 'cm Xlink' command). Of course the Xlink at the "WebApp2" repository is still pointing to the changeset 1 of the "CommonProject" repository. Regarding the selector question, the PlasticSCM 3.0 selectors are not available in PlasticSCM 4.0 so as you saw the selector rule is not going to work. Manu. Link to comment Share on other sites More sharing options...
Corey.Caldwell Posted January 24, 2012 Author Report Share Posted January 24, 2012 Is there any way I can share the CommonProject among the other repos? I currently have 4 different projects that I need to share that common code with. Link to comment Share on other sites More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 Well yes, using the Xlinks. But keeping in mind how is the usage of the Xlinks. Link to comment Share on other sites More sharing options...
Corey.Caldwell Posted January 25, 2012 Author Report Share Posted January 25, 2012 That's what my question is: how can I set up xlinks so that when i change CommonProject from WebApp1 that those changes will show up in WebApp2? Is there syntax to point the xlink to the latest version instead of a specific changeset? Having to remember to manually update the xlink each time I go into a different application isn't very practical. If xlinks can't currently do this, how can I set up my workspace with multiple repositories like in previous plastic versions? Link to comment Share on other sites More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 Hello Corey, right now it's not possible, by July of this year we will have it, but not now. Manu. Link to comment Share on other sites More sharing options...
Corey.Caldwell Posted January 25, 2012 Author Report Share Posted January 25, 2012 Well I've done some testing and tried to find a work around but I am out of ideas. Unless I can get the common project shared among the other projects, I won't be able to migrate to Plastic. If an xlink gets out of date while you're working on it (someone checks in a change from another repo) everything you've worked on is toast. Is there any way to enable mounting or even nested workspaces? I'm trying to get away from TFS and was looking forward to the superior branching and tools of plastic, but some method of sharing some common code is critical to our implementation. Link to comment Share on other sites More sharing options...
manu Posted January 27, 2012 Report Share Posted January 27, 2012 Hello Corey, I've just sent to you a private message regarding the situation. Manu. Link to comment Share on other sites More sharing options...
Corey.Caldwell Posted January 31, 2012 Author Report Share Posted January 31, 2012 For anyone else out there trying to figure out this scenario, I believe I have a solution. It will involve a bit of fiddling and some command line shenanigans, but I trust this will only be temporary until the Plastic team works something easier out. Currently you can have a common repository shared between multiple other repositories with xlinks but there are a couple caveats: If an update happens in your common repository, either through a writable xlink or directly in that repository, your other xlinked repositories will have an out of date copy of the common repository. If you're using a writable xlink and your version of the common repo is out of date (i.e. newer change sets on the branch) and you go to check in, you'll be prompted for a merge. The important part is that we can work through both of these issues to keep working without loosing any of our work. An important thing to note with xlinks is that they currently only point to a specific change set or label. It is important to understand this because this is why your changes through 1 xlink to a common repository don't automatically go to the other xlinked locations. Even though you see a new change set in your common repo, the other xlinks are still pointing at the old change set. Here's my example setup: Repo: Common Location: C:\Common[*]Repo: WebApp1 Location: C:\WebApp1 XLink: cm xlink -w c:\WebApp1\Common / cs:1@Common@Server:8087 [*]Repo: WebApp2 Location: C:\WebApp2 XLink: cm xlink -w c:\WebApp2\Common / cs:1@Common@Server:8087 Basically my goal here is to have a shared library between both WebApps, be able to update that code from either WebApp, and have those changes show up in the other WebApp. The first obstacle we'll run into is #1 from above: update common from WebApp1 but my changes aren't in WebApp2. This is because the changes to Common from WebApp1's XLink will have generated at least 1 new change set in Common and WebApp2 is still pointing at an out-of-date change set. To fix this, we'll use xlink with the -e option to point that xlink at a new change set or label: cm xlink -e -w c:\WebApp2\Common / cs:2@Common@Server:8087 Check that change in and update your WebApp2. You should now see the changes of whatever change set or label you updated it to. Please note that if it was a read-only xlink, do not put in the -w option. If it is a writable xlink, the -w option will be required. The -e option is only (from what I can tell) for updating the code that the xlink point to and cannot change the writability of an xlink therefore you must maintain the same options when you update the xlink. To tackle #2, we'll make a change in WebApp2's common code, and check it in. Without updating our xlink in WebApp1, we'll make some other changes in Common. When we go to check this in, we'll get a merge warning and the choice to merge now or merge into another branch. If you choose the first option, you're shown a blank screen with nothing to merge. This isn't terribly intuitive but its also not where we want to be. Close out the merge screen and go to check in again. Choose the second option and merge those changes into a new branch. Now go and update the xlink for WebApp1 to point to the latest change set or label in common, check in that change, and update. Now merge in the branch you just made with your common changes and those changes will now be in the Common repository. The important thing to remember here is that, at least in its current state, a setup like this will benefit from good communication about what development is happening on the Common code but if you do happen to make concurrent code changes or forget to update your xlink, you can still move forward without losing the work you've done. Now that I feel like I have the xlink system figured out, here's what I'd like to see in future Plastic releases: XLink GUI Notifications for out-of-date xlinks More intelligent merging when trying to check in changes using an out-of-date xlink The ability to point an xlink to the current version rather than just a fixed change set or label Link to comment Share on other sites More sharing options...
manu Posted February 1, 2012 Report Share Posted February 1, 2012 Hello Corey, thank you for the elaborated post, I really appreciate it. The last 1, 3 and 4 points are going to be developed due to the users can't work fully with plastic and Xlinks in this scenario. Regards and thanks again for the clear explanation. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.