Jump to content

Workflow for read-only xlinks


gweronimo

Recommended Posts

Hi! There seems to be some usability missing when working with read-only xlinks.

Having to perform a full cycle of [edit xlink] + [checkin] + [update] just to fetch a different (read-only) revision of the xlinked content seems both non-intuitive and counter-productive.

The workflow would be much improved if there was an option to immediately update the (read-only) contents after editing the target changeset of the xlink. I understand that this can't be done for writable xlinks, but that is exactly my point! Since the two variants are not equal, the workflow around one should not be forced to mimic the other.

The problem with having to checkin + update is that the rest of the code may be work-in-progress and we may need to make further changes due to the incoming updated xlink content. We'd like to be able to build and test with new xlink content without having to checkin first.

The only problem I can foresee with such added functionality is that the user may have pending changes inside the read-only xlink folder. (These changes are quite useless since they can't be checked-in!) In this case, we could simply be warned that we need to revert these changes before editing (and refreshing) the xlink.

I'm aware that a similar workflow could be achieved with writable xlinks, but that seems rather complicated due to branch expansion rules. It also seems unpredictable in our use-case since we have multiple repos xlinking to the same target repo, with different branch hierarchies in each.

There have been some previous topics requesting this feature:

NOTE: In the above topic a workaround was suggested for this scenario. However, I tested this idea and it no longer seems to work at all. I had to shelve my non-xlink changes and revert the experiment in order to get back to a workable state in my workspace again.
 

Best regards,
Göran W

Link to comment
Share on other sites

Hi,

If I properly understand, you request is: "Allow editing an xlink changeset and getting changes temporarily without commit xlink edit"

The workaround proposed by Manu in the other forum topic should at least work for writeable Xlinks.

You can include your request at: https://plasticscm.uservoice.com/

Changing the way the Xlinks work: edit + checkin + update would require some important core changes so not sure if we can adress it in the near future but we will share your request with the team.

Reards,

Carlos.

Link to comment
Share on other sites

The proposed workaround by Manu would probably rarely be useful for writeable xlinks, while a similar (but working) workaround would be very useful for read-only xlinks. The whole point of my suggestions was for read-only xlinks only. Being able to update a read-only xlink without prior checkin would be very helpful indeed. The optimal workflow for us would be as follows:

1. Make changes in the xlink-target repo. Checkin.
2. In the xlinking repo, edit the (read-only) xlink to point to the new revision from the target repo. Update (refresh) its contents (without checkin).
3. Build and test. Make changes to the code that uses the xlinked content until everything works fine. Checkin.

Without the ability to update/refresh a read-only xlink, in times of frequent changes to the xlink-targeted repo we'll get lots of "unnecessary" checkin+update cycles where the only change is an xlink edit. Also, there is no way to temporarily test an older/newer revision of the xlink, without first checking in and then later having to re-checkin the xlink edit.

As for writeable xlinks, I would have to setup a branch expansion rule and I would then get automatic branching happening? This is something we don't want and that could possibly run out of hand since we have xlinks to the same repo in two different repos with different branching patterns. I'd like to hear your advice in this scenario. For example, is it possible to use writeable xlinks without automatic branching?

Best regards,
Göran W

Link to comment
Share on other sites

Quote

As for writeable xlinks, I would have to setup a branch expansion rule and I would then get automatic branching happening? This is something we don't want and that could possibly run out of hand since we have xlinks to the same repo in two different repos with different branching patterns. I'd like to hear your advice in this scenario. For example, is it possible to use writeable xlinks without automatic branching?

No, as soon as you create a task branch in the parent repo, the same branch will be created in the Xlinked repo. What you can customize is where the new branch will be created via auto-expansion rules.

Having Xlink poiting to the same repo from two different parent repos is normally a not reocommended workflow. Anyway, sometimes it could be useful (eg: sharing different library versions between different projects). We have a blog post explaining this scenario and how you can customize the autoexpansion rules based on your needs:

http://blog.plasticscm.com/2014/08/how-to-share-engine-repository-between.html

Regards,

Carlos.

Link to comment
Share on other sites

  • 1 month later...

A variant of the originally mentioned problem becomes very apparent when performing a merge that includes a modified xlink-target-revision. 

If the updated xlink-contents are needed for the merged code to build correctly, then the build will fail and there is no way to verify the build BEFORE checkin of this merge.

(Performing an Update is possible but it does not help, since the xlink-contents are not updated to the new revision (since the revision-change is not checked in)).

Link to comment
Share on other sites

Quote

 

A variant of the originally mentioned problem becomes very apparent when performing a merge that includes a modified xlink-target-revision. 

If the updated xlink-contents are needed for the merged code to build correctly, then the build will fail and there is no way to verify the build BEFORE checkin of this merge.

(Performing an Update is possible but it does not help, since the xlink-contents are not updated to the new revision (since the revision-change is not checked in)).

 

Sorry, but I don't properly understand this variant. Could you let us know the steps to reproduce? Or we can also arrange a meeting to review it.

Regards,

Carlos. 

Link to comment
Share on other sites

OK, here are example steps to reproduce:

1. On a child task branch, edit a  read-only xlink to point to a later version that contains "breaking changes" to some code that is included in the build on the current repo.

2. Update the dependent code to build again, after adjusting to these breaking changes.

3. Switch to the parent branch and Merge back the child branch.

4. Now without Checkin, the merged-back code will not build (even though it probably should) - since the xlink still contains older code.

5. Checkin. Code will still not build in your local workspace.

6. Update workspace. Now at last the xlink is updated and the build will work.

Regards,
Göran

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...