Question about XLinks

[sbrassard]

Plastic Peeps,

Lets say I have 3 websites that I maintain. Each website is in its own repository. All three of these websites use some common javascript code / controls. So, lets say I create a repository for common Javascript code. I want to be able to change/update code using any of the websites projects (from within visual studio) and link this common javascript to each of my projects.

So, when I work with Website1 and make javascript changes/fixes to bugs, Website2 and Website3 will benefit from those changes that I make. This should work regardless of which Website I am currently working with.

How can I do this with plastic? Does each link get versioned...in other words, will my changes not appear in other projects if I work in one specific project making changes to the Javascript code?

I need a solution and not sure what I can do, using plastic...

Thanks

[manu]

Hello sbrassard,

in your scenario only the Webiste1 project will be pointing to the HEAD of the Javascript xlinked repository.

What you need is to update, manually, the xlink target on the Website2 and Website3 repositories. I'm afraid that right now it's the only way that can be done.

[carpediemevive]

I know some people want to have the XLinks always pointing to head, but realistically it makes sense. Each project of mine uses a common code base, but that code base evolves as well. Most of the time it evolves along with a particular project, but I don't just want to automatically update each project with the new code base every time. All it takes is proper versioning of the common code base, and tracking which project is on which version of it. Then updating the version of the code base becomes a change similar to updating a version of any third party library you might use.

[sbrassard]

I know some people want to have the XLinks always pointing to head, but realistically it makes sense...

Yes! My thoughts exactly. Would it be possible to code up an option for creating an Xlink to always point to head? Some kind of specialized xlink that can be created using a parameter like "-current" or "-present" meaning it will create the xlink to always read the head and keep current when the head changes. Updating the Xlinks manually just doesn't make sense. It's just as bad as having to open the other projects just to modify/copy/paste the same javascript code for each project.

I would like to see a solution for this if possible.

[carpediemevive]

Just because I'm dying to know, why wouldn't you want your projects to always point to the same version until you tell it you want it to be on a different version? If one of your websites was built on a specific version, wouldn't you keep it on that version until you make the conscious decision to upgrade it?

[sbrassard]

I am on a team developing a web application software product. We have 3 other products that take advantage of our custom javascript library controls (dropdowns, grids, etc). For a while now, we would work within one web application, make changes to a folder containing javascript code, and then copy that code to our other web projects to make sure they benefit from the changes we made. Of course all code goes through QA to catch any bugs, etc. So, sitting back and thinking about this some more, does it really make any sense to have an xlink point to head? I first thought it would be a good idea, but now I think about it, if any other bugs get introduced, we don't want to negatively affect our other projects. Maybe manually updating the xlink isnt so bad after all?

I would like some discussion on this. Let me know your thoughts. At this point I'm kind of on the fence here. That's why I started the thread...

[carpediemevive]

I can say you're certainly not alone in wanting everything always updated; I've seen others on the forum ask for it, and I think there's a request for it on the uservoice.

I share your concerns however with doing that, on a practical level. Yes, updating all the projects can seem like a pain, but if you happen to be working in a project adding a new feature and you see a bug, now it gets more complicated to trace that bug back. Maybe it's because of this common library code, or maybe it's something you changed.

I do still see myself working on a shared library in congruence with a new project. However, I would ideally create a branch for this development work, and using a writable XLink to it for the one project alone. Then when that new development work is done, and it's gone through QA, I'd merge it back up to main, and tag it as a new release, available for projects to consume when they are ready.

[psantosl]

Hi all,

I'll try to address again this concern about "automatic Xlinks pointing to head".

First, one question: are you using writable xlinks or readonly xlinks?

Now, my explanation:

• It would take like nothing for us to implement "dynamic" read-only Xlinks. Making writable ones dynamic (pointing to head) would be much more complex and probably out of the scope.
  
• 3.0 users (and even older) will remember that our "mounts" allowed you to load other repositories dynamically, which used to sound like a good thing... but error prone. Let me explain why in the next bullet point.
  
• With 4.0 we wanted to achieve "immutable changesets": once you checkin, you're able to reproduce exactly the same configuration just "going back and loading this changeset". You can't obtain this if you make your xlinks dynamic and able to load whatever is on "head", correct?
  

So, I'd love to hear more from you.

What about writing down here the pros and cons of dynamic read-only xlinks???

If they really make sense we'll get them implemented asap.