Soho Posted June 13, 2012 Report Share Posted June 13, 2012 Hi, Just a general warning. We started using xlinks a lot, since it is a really nice feature. However we are daily running into various problems with Plastic because of this. It seems as if xlinks have not been tested thoroughly, so I would recommend that people wait using xlinks until the Plastic team has made this feature more stable. Among the problems: You have a project where you have some library that you want to move into it's own repository in order to share it between projects. This should be one of the core benefits of xlinks. In order to break as little as possible you keep the name of your library folder. This makes Plastic go crazy. For once you cannot delete the old library folder and xlink the new in an atomic changeset. First you have to delete the folder in one changeset, then you add the xlink. Secondly, if you try to merge with a branch that contains such a library replacement (containing both the delete changeset and the xlink add changeset), Plastic completely deadlocks. Plastic accepts the merge, but refuses to checkin the changes, since it contains both a folder delete and an xlink add to the same folder, which cannot be contained in the same changeset. The workaround would be to first merge specifically with the changeset containing the delete, check that in, and secondly merge with the whole branch and check that in. To do that now, you would have to undo the "bad" merge first. However, Plastic will not let you undo the merge either. So you cannot checkin, you cannot undo. The only thing you can do is to delete your workspace and start all over merging in two steps as described. Third, ever since we started using xlinks our build server TeamCity refuses to checkout repositories. Not, completely, but most of the time. It seems as if the TeamCity plugin doesn't like xlinks, so you have to checkout the repo manually. Not something you want to do with in an automated build system. In general Plastic has become rather unstable lately and we suspect the xlinks to be the culprit. All in all we are rather disappointed with xlinks. It's a greate feature, but it is very unstable. Note that we use writable relative xlinks. We haven't tested if Plastic has a problem with not-writable absolute xlinks. Link to comment Share on other sites More sharing options...
psantosl Posted June 13, 2012 Report Share Posted June 13, 2012 Hi Soho, Thanks for your feedback. We'll definitely try to figure out what's wrong in your case. A few notes about Xlinks though: We use writable xlinks (relative repository) internally. All our code changes use this structure. We've been using them for months now (like 8 months or so). We do merge them on a daily basis, we use them to create every new release. Every single task developed down here uses writable, relative xlinks. One of our largest customers (1000 concurrent developers using 19 replicated repositories on 3 continents with a code base of 400k files in a single working copy and merges involving hundreds of thousands of files) uses writable Xlinks on a daily basis. So, yes, they're not bug-free, of course, but "not been tested thoroughly" is maybe a little bit tough considering the scenarios described above That being said, I already forwarded this thread to one of our senior engineers to take a look into it in a few hours. Thanks, pablo Link to comment Share on other sites More sharing options...
Soho Posted June 14, 2012 Author Report Share Posted June 14, 2012 I know that "not been tested thoroughly" is a bit of a provocative statement, but a large company using a specific feature may not imply thorough testing. Large companies tend to have strict policies on how to structure their work and they may only use some feature in a very specific and consistent way. We had the same discussion with the countless bugs in the Plastic 4 VS plugin (the Plastic 4 plugin is much better, thank you). Of course I understand that you prioritize your large customers, but I stand by my warning. Xlinks is a very desirably feature missing in many VCS systems, so we embraced that feature with joy. Unfortunately we ran into several showstopping problems causing lost hours and a dead build server so we had been better off without xlinks. Perhaps my warning should be rephrased to "test the xlink feature you want to use before going all in" or "Wait a whilte for xlinks to mature". Link to comment Share on other sites More sharing options...
psantosl Posted June 14, 2012 Report Share Posted June 14, 2012 Ok, we're investigating your bug. Anyway: I hope the scenario involving deleting a directory and adding a xlink with the same name is fortunately not very common. Link to comment Share on other sites More sharing options...
Soho Posted June 15, 2012 Author Report Share Posted June 15, 2012 Super! Replacing a directory with an xlink with the same name was very natural for us. The scenario was this: We had existing projects with some libraries that we wanted to share between other projects. The logical step was to create a new repo with the libraries and replace the library folders with xlinks to the new repos to avoid breaking builds and dependencies. I don't think this is a corner case scenario, it was the most obvious thing to do for us in order to share library code with xlink. I like to point out that I think xlinking repos is an awesome feature. Especially the auto-branching feature is really nice. In the old days we would have to use extreme caution if we wanted to change a shared library to avoid breaking other projects. Now we just code away, knowing that nothing will break and yet we can still merge new features into the main branch in a controlled manner. This is really good stuff. Now, get rid of those nasty bugs, please. Link to comment Share on other sites More sharing options...
Soho Posted June 29, 2012 Author Report Share Posted June 29, 2012 I just noticed this in the release notes: External Release 4.1.10.303 (Jun 23th 2012) ==================================================== Bug Fixed a checkin issue that left a tree pointing to a missing existing revision on really special conditions. Fixed a checkin issue that happened when we were trying to commit a deleted plus and an added xlink on the same path. I assume this means that the problem has been fixed. That is good news for us. I do find it a bit odd that you call converting a folder to an xlink version of that folder "really special conditions". Really special conditions should be something like "if a checkin was done with a folder replaced by a xlink exactly the second when daylight-savings-time changed in a leap-year, an error would occur". That is special. Link to comment Share on other sites More sharing options...
manu Posted June 29, 2012 Report Share Posted June 29, 2012 Yep, that one is for you! Link to comment Share on other sites More sharing options...
Soho Posted June 29, 2012 Author Report Share Posted June 29, 2012 I appreciate it. The issue resolved would affect anybody who wants to replace library folders with xlinks. For our purposes, this is where xlinks really shines brighter than other common library sharing options. It makes modifying shared libraries much less painful and risky. Apparently xlinks was not created for replacing library with sharing potential with shared repos, but this was the use we found most obvious. Link to comment Share on other sites More sharing options...
manu Posted July 2, 2012 Report Share Posted July 2, 2012 Yes, you are right. The case was a "regular" one and it was not supported. I think a lot of users will avoid the original issue with this new release. Link to comment Share on other sites More sharing options...
cidico Posted July 2, 2012 Report Share Posted July 2, 2012 Well, I know that this question is not related to the subject, but I don't want to create a post just to ask this... Are you thinking about supporting xlinks outside the main workspace folder? Link to comment Share on other sites More sharing options...
manu Posted July 3, 2012 Report Share Posted July 3, 2012 Are you talking about downloading external repositories content outside the Plastic SCM workspace? Link to comment Share on other sites More sharing options...
cidico Posted July 3, 2012 Report Share Posted July 3, 2012 No.. the limitation of Plastic only letting me create an xlink in the root folder. Link to comment Share on other sites More sharing options...
manu Posted July 3, 2012 Report Share Posted July 3, 2012 Ok! I didn't understand you, sorry. We are thinking about it, but they will be read-only. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.