Great, thanks!

I too am waiting for this to happen, if only for read-only xlinks!

For the record, we have used the following workaround to avoid creating several target repositories for related xlinks:

In the target repo, create one top-level branch for each "subfolder". Then you can make your xlink target a specific branch among these.

TIP: We also cloak the contents of our read-only xlinks to avoid downloading when not needed. If you are to try this, make sure you don't cloak the actual xlink folder! Instead, use the following kind of rule in cloaked.conf:
/path/to/my_xlink_folder/**

Thanks 'Admin'

A related item which I'll just toss into the pot, is the ability to create a workspace on a subtree. Strikes me that an xlink is much like a nested workspace, so if you can create an xlink to a subtree, then you should be able to create a workspace to a subtree. (Plastic 3 had selectors that could do this, right?). Of course the readonly-vs-readwrite issue raises its head again in this case.

On the other hand, I'd quite like one-off readonly exports of subtrees. Eg for a build machine (which may be the same machines as my development box). I have build scripts now which do svn export on a subtree. There is no CM Export command. THis is getting off the topic of this suggestion, just mentioning it because it could be related.

This request was first made now over three years ago, and at the time the Codice response was "read-only Xlinks it would be straightforward"

It also has 108 votes, more than just about any other request (apart from "Public API" which granted could be useful ). And there are a couple of other requests that hint at the same idea.

HOPEFUL PLASTIC COULD GET THIS SOON!

There is no easy workaround that I can find (short of spawning repositories for each and every possible subtree anyone might like to xlink). It's just about the last blocker (apart from the work involved in the transition) for me moving a large chunk of code (currently in two other SCMs) to plastic.

There is also an analogous (although not identical) feature in a number of other SCM products: svn:extern, Vault shared folders . and even GIT subtree merges (but not submodules).

From what I can glean from the comments here, the 99% use case is readonly. And by readonly I mean you can change files but cannot commit them back. Granted we then have to handle merges ourselves (perhaps through a different working copy of the full repository).

Perhaps a better term than 'readonly' is 'subscription' - we want to subscribe to a particular file or set of files, either the latest available or pinned to a particular changeset. (Perhaps with access to the original repo's change history for looking at comments etc, but that's an aside).

Failing that, a decent whitepaper on xlinks vs svn:externals and explaining why creating new repositories for every subtree isn't frightening (assuming it isn't, the idea frightens me!)

Actually I just noticed that Plastic appears to have no equivalent for svn:export either, which breaks one possible workaround I had in mind. But neither does git.

All

I won't vote for this. Because this will break the git bisync.

Hi Alberto,

We already have "merge-to" which is merge support on the server side, no need for a workspace ONLY IF there are no conflicts.

The reason why we don't like the idea of workspace-less merges is the following: after a merge you should build your code, and you won't do that if you don't have a workspace. In DVCS every changeset is not only a "checkin" is also an entire snapshot of the repository at a given point. An snapshot *should be* something that actually existed on your workspace, not only something made up on the server side that was never even built.

That's why we're somehow reluctant to go ahead with the idea.

It would be great to improve tools for merging on server side without need of local workspace involvement. Some kind of "shelves", as a serve side support "workspace" would be ideal for management of conflicts, or chain-of several merge for out-of-local-workspace operations.

This work would help to only for writable partial xlinks, but also for a fully supported server-side merge of branches with conflicts, as even thought current feature is great, it can be easily blocked by small conflicts.

This primitive of 'shelve/virtual workspace', would also help to backup local changes to avoid to be destroyed before merge operations ( in collision with local changes not uploaded yet ).

Best,
Alberto

A vote for read-only partial xlinks. That solves the component use issue where the consumer does not need to get everything.

I would like to see read-only xlinks, similar to svn:extern. This would be very helpful so that, for example, the dll from a shared component could be included in another project. This should include the ability to specify a specific changeset on the xlink so that a release manager can control which version of the xlink'd content is included in a project.

Yet another thought of why xlinks to a sub-tree might be necessary or much better over xlinks to a whole repository.
If I develop a shared component (surely an obvious reason for xlinks in the first place) there may be source code components which do not need to be shared, or indeed must not. For example, I might have a directory structure like this:

(Root) --- public_components (scaled images, header files, whatnot, maybe released prebuilt components)
|-- documentation
|-- image_source (eg .PSD files)
`-- tools

Anyone xlink-ing to this would want to link only to the public components and not pull all the other stuff which is only relevant to someone actively maintaining the project.
You could argue this should be done in its own repository for the public components, and one for the internal source code, but whichever way you look at it, it is more work for the developer and proliferating more and more repositories.

Sorry that should be " readonly xlink would still allow IMPORTING the code

I'll just chip in here: readonly xlinks would be better than nothing.
I've got two scenarios for xlinks

1. Have a "third party source" repository, with useful libraries. In this case our company does not ever change the code, or if we do it is an emergency patch for which taking extra trouble over a commit is not a problem. The third party tool may come with several different subfolders (examples etc) of which only one is of interest to a developer. Read only xlinks are completely sufficient - indeed probably preferred - for this., but we don't want a different repository for each bit a developer might share, there might be a hundred of them after a while..

2. Internal libraries - the only difference from the first scenario is that our developers maintain and extend them regularly. The use in our customers projects might be quite granular - for example I have a handful of useful C# classes - like a command-line parser - which I want to include in a customer program without bringing in an entire .NET assembly or worse the our entire suite of .NET library components. (I might be writing a tiny 100-line utilty program for example).

In this second case, readonly xlink would still allow important the code even though updates would have to be more carefully managed. (However it would still be necessary to be able to change files in the workspace, even if they need then to be copied to another workspace before checking in).

Read-only partial xlinks would be all I want.

This would allow a unified "sdk" repository, but a project can cherry pick which sdks and versions it needs.

For read-only Xlinks it would be straightforward, but it would be more difficult for writable ones.

We're still studying the second option, that's why it is not yet implemented.

The reason is not simple to explain: if you have a "partial tree" mounted, and you modify it, when you merge it back, what happens if there are conflicts outside the "tree" you're loading that can affect it? (like a move, or code being added outside it that won't be merged cause you're not loading it but then it would be lost).