Using the selector feature

[Shacharpr]

Hi

I have a repository with few components, each with multiple number of folders.

I am looking for an easy way to configure Plastic so every user will get a view (and workspace update) of only his/her component/s.

I tried the selector feature, but it does not seem to work...

I have set the below where I like to get all folders that start with 'cord'. What am I doing wrong?

path "/cord*/"

br "/main"

co "/main"

Thanks, Shachar.

[manu]

Hello Shacharpr,

are you using Plastic SCM 3 or Plastic SCM 4?

If you are using Plastic SCM 3 you can take a look into this document: http://www.plasticscm.com/infocenter/technical-articles/component-based-development.aspx

If you are using Plastic SCM 4 you have to use xlinks: http://www.plasticscm.com/releases/4.1/manuals/en/xlinksguide.pdf

[wnicholls]

Sorry to jump in on the thread, but If I read this right, then Plastic SCM 4 broke a whole lot of scenarios, to the point where today I'm running straight back to Subversion (i've been trying to evaluate PlasticSCM as a replacement with considerable difficulty - but this is about the only deal breaker, I suspect)

For example I have a project which consists of three parts

- A bunch of .NET / C# Windows components - class assemblies, a web service module and so forth. This must be develped under Visual Studio on Windows

- a Website module developed in DotNetNuke which must be worked on in a different folder E:\Webs\......\desktopmodules\myproject\ since the web server can't access the normal dev drives.

- An Android app, which must be developed under Eclipse on linux.

Thus it is structured (in Subversion as it happens) as a repository with three top-level folders, call them: /source, /webmodule, /androidapp,

So under Subversion I simply checked out the appropriate subtrees in each working directory. This works perfectly in Subversion.

In that (older) article (Component-based development) , under the title "Loading a subtree of a repository into a workspace" describes my scenario perfectly. I had imagined that for example my selector for the Eclipse workspace would be:

repository "project@server:8087" root "/androidapp"

path "/"

br "/main"

co "/main"

And similar with root clauses for the other two. Or possibly, I'd be able to use one workspace

It looks like that with v4, using xLinks, effectively every developer potentially has to create a repository PER WORKSPACE. Worse, since xLinks can only be pointed to the root of a repository and not a subtree, I now potentially have to split the project repository into three/

This is ridiculous. Tell me it cannot be true! And if not, how am I supposed to do it now? ( Or did you not place a high value on the potential customers referenced by "Your organization might place a high value on the simplicity of maintaining a single central repository" ? <g> )

Ironically the ability to effectively manage our customers with a SQL server database each, linking to one or two shared repositories with our and third-party libraries, is a real selling point for me. While I'm on the rant, I would also place a very high value on xlinks to subtrees. In fact, to individual files.

Thanks for any suggestions you can make

[wnicholls]

While at it, the comparison table at http://www.plasticscm.com/infocenter/comparisons.aspx claims "Multiple repositories mounted on a single workspace"

If I read you right, this is no longer true. Or it may be literally true, but it now goes in the bin of 'features that marketing tout as an advantage over the competitors, but are actually useless". It wouldn't be the first on that table, I must say ( what use is fast-import if none of the competitors have fast-export? Although if you put git in that list at least one other product would get a tick)

[Guest]

Hi wnicholls:

First of all, before making a statement, please try to have the whole picture clear, right?

Good, then, regarding your question:

- We've introduced the Xlinks feature in 4.0 which is much more powerful than mounting repositories, because you only need to setup the xlinks in a changeset and from that point on, every user that downloads that changeset will be downloading the proper versions of the proper repositories, without having to setup anything else. In 3.0 you had to setup a complex selector and share it with all your team so that they would set it up. Now that's not needed anymore.

And you defnitely don't need to setup a repository per workspace. I recommend you to read thoroughly the Xlinks guide to really undestand how xlinks works, because it's a nice feature that anybody else has and there're lots of people that enjoy it:

http://www.plasticsc...xlinksguide.htm

On the other hand, you're pretty right when you say that (currently) xlinks don't allow to xlink a repository from a directory deeper than the root of the repository. What's true (right now, but we'll develop something to improve this in the near future) and if that's a showstopper for you then you should consider using Plastic 3.0 or other tool such as SVN or Git, if that suits you better.

Finally, when talking about fast-import and fast-export: if you read the documentation, you'll notice that:

Fast-export is useful when migrating data from Plastic 3.0 to Plastic 4.0. Furthermore, it is useful when it's about migrating Plastic data to Git. And from Git to any other SCM tool.

Fast-import is useful when migrating data from Git (and probably from any other SCM tool to Git before) to Plastic SCM.

Last, but not least, please review your writing on your post; there's a lot of professional work made by really good professionals behind the scenes, and every single decision is made on purpose and I can tell you that there's a good reason for it. We are humble with our errors, bugs and issues, but please, be kind; I'm just asking for a little bit of patience when talking to us.

Best regards,

Luis

[wnicholls]

My apologies if you feel offended. It is so easy to get the wrong tone across when writing to a stranger (or worse, an internet full of strangers). I am (naturally) offended back <g> - I'm very aware I am new to Plastic and I took a lot of care to ensure that post had all the information required. And the only statement I made which I might change on a rethink is marked with a <grin> . But wilth all mutual offence out of the way, many thanks for your thorough reply. and on with the problem in hand.

The very first page of the XLinks guide states "An Xlink .. is a directory entry in your repository tree that points to another directory in a different repository".

That is NOT the scenario I am talking about. I want to check out only part of a repository in the workspace. This would imply "a directory entry in your WORKSPACE that points to .. a directory in a repository". Even if xlinks could be somehow put into a workspece, they can't be pointed at a subtree, only at the root of the repository. And even if the partially-promised improvement to allow readonly xlinks to subtrees comes along, it still fails.

Both Shachar and myself have outlined a scenario that could be done fairly easily in Plastic SCM 3 and asked how it can be done in Plastic v4. Both Manu and yourself has said "use xlinks instead" - but neither of you have actually said how that is supposed to address the issue.

( Your advice to stick with svn or try Plastic 3 is probably good, in fact - but poor salesmanship! However if I was completey happy with subversion (or Vault, the other SCM I use and would like to replace) then I wouldn't be evaluating Plastic, would I? <g>

Just to be clear, I'm very impressed with the thought that has gone behind Plastic, and there's a lot of really really nice stuff there. But to use it, I do need to find out to migrate our existing data and then how to adapt our ways of working. And convince the other developers this is worth the trouble).

[Guest]

Thanks for your nice reply.

To be honest, I cannot promise you that we will develop xlinks that load partially a repository in the very next weeks. Probably that's poor salesmanship, but you know, I'm a developer... and I'd rather to be honest to you, first of all.

Anyway, could you please tell me why is so important to load only partially a repository and not the full one? Maybe we're pointing to the wrong problem or maybe you really need to do what you want to do and there's no other possibility, I just want to know.

Many thanks,

Luis

[CG]

@wnicholls,

I think I might be missing the specifics of your problem, but wanted to offer a few thoughts to see if it might help you out. I use Plastic and xlinks with component development and it's been very easy going.

There are lots of ways to structure things. My first assumption is that it sounds like each of your three pieces need to be developed (or should be developed) separately and independently from one another (i.e. you aren't developing on linux and windows at the same time from within the same workspace).

What you could do would be to create three repositories, one for each of your pieces (your components, yuor web, and your android app). If you absolutely NEED to see the source of the other two in each repo, you can simply create an xlink to the respective repositories.

So your components repo might look like this (at the top level):

/androidApp (an xlink)

/componentSource

/webModule (an xlink)

your webModule repo might look like this:

/androidApp (an xlink)

/componentSource (an xlink)

/webModule

and similarly for your android app repo.

So, if you're on linux/unix and pull down a version/changeset of the android app repo to your workspace, you get the other two relevant branches/changesets from the other repos as well.

Now you can't link to a specific subfolder in those repositories, but so what? You may have to change a few paths from what you have now as your tree will be slighlty deeper, but that's it.

Also, you said:

I want to check out only part of a repository in the workspace.

Note that the contents of repos don't get checked out when you pull them down into your workspace, only when you specifically perform a checkout.

What's the specific use case you are trying to accomplish that you can't get to work with xlinks?

With regard to Shachar's use case, that seems like a poor setup for component development if access should be restricted--I would think truly independent components (where developers working on one can't see another) should be versioned independently in separate repos (that way access permissions could easily be set to restrict certain people from being able to see the code). If Shachar's issue is really just one of convenience and not wanting users to have to pull down the whole repo, then it is true that that use case can't be accomplished...however, I don't see that as an issue--in the same way there may be a lot of crud in a repo I never touch, I just ignore that crud and focus on what I need to.

My suggestion is to create light-weight repositories that contain only those items that should be versioned as a unit independent of your other items/components/apps you may have. With shared components, for example, we stick to semantic versioning and give each component or series of components that are developed as a single versioned unit their own repository. When they are ready for release the binaries are published to a package server and the source is published to a symbol server. Then our webapps or other consumers of those can integrate them as needed, using the version number as a guide for integration (based on the semantic rules). In this way we have small, fast, light-weight repositories that are easy to get in and out of, and very easy to see version related branches and the specific tasks that went into creating the release for a specific version. And if you need xlink integration, you can simply point your xlinks to the changeset that represents the working version you are interested in for that component.

[wnicholls]

@luis, @CG Thanks.

I'm having to move my attentions else where for a while, but in short. .. as much as I can manage to be short.

This is not necessarily a valid argument, but checking out subtrees on a repository is something that every other RCS/SCM I'm aware of is able to do - well (and this may be key) non-distributed ones anyway. I'm not sure git can. Links to subtrees is also very common - VSS, Subversion, Vault all have it (although not necessarily to external sources). Not every user - in fact, I would say very few users - of Plastic is going to have a clean slate to work from, they will have history with other systems and will expect equivalence. And also need to migrate existing work practices and folder structures.

( And sorry Luis, but that comparison table (http://www.plasticscm.com/infocenter/comparisons.aspx) is a typical marketing device: doesn't list any feature that Plastic does not have, doesn't explain what the terms mean, and is particularly inconsistent in its treatment of Subversion. To be taken with massive doses of salt - great for showing to managerial types to say 'look how fantastic is this product I want to buy" though <g> Not that, for example, http://en.wikipedia.org/wiki/Comparison_of_revision_control_software is an awful lot better. Distilling comparisons down like this is HARD)

Following on from @CG:

Using a workspace with cloaking/and or multiple repositories (sounds awfully like what I was complaining about - a repository per workspace) will also add depths of directory structure that aren't there currently. To migrate to plastic, I may have a variety of build scripts and project files to change.

Using your logic, my example project needs 3 repositories where in subversion it is in one? and I didn't even mention the CASE tool and all the database scripts.

We have about 15 year's history of source code in subversion and in a single Vault repository. I don't actually like using one huge database, but I would like to keep it down to one per customer .. taking the active ones, that's about 10 or so. (This is historic due to limitations of Visual SourceSafe which couldn't do shared folders outside of a single database. The svn stuff is broken up better)

Given the limitations of xlinks only pointing to a repository, I suspect I would need upwards of 60 Plastic repositories to replace just this one in Vault. We have a lot of shared libraries but not every project that needs to use a shared library will need everything.

I guess my real annoyance is that in every other way Plastic v4 seems to be a silver bullet - cross-platform, GUI on Linux , decent SQL-database backend, loaded with features. But it's missing two crucial features that every other vcs I've used has had for years .. from the start in the case of my two current ones (Subversion, Vault). I don't even mind that, but I'm struggling with the workarounds.

[manu]

Hi there!

are we a silver bullet? Really strange since branching and merging are key for agile techniques.

Does subversion support CRUCIAL and BASIC features as branching and merging are? I'm afraid not. SVN does not support complex Parallel development, which in today’s development environment, is important for companies of all sizes.

Subversion does not provide any merge traceability, resulting in time wasted by developers attempting to address the complexities of code integrations. I can provide you a few daily merge cases where SVN really mess the result.

Is SVN distributed? I'm afraid not, but maybe you like the archaic cavern patch system...

Let's talk about the visualization, can you provide me a better repository overview than the branch explorer? Please post it to us. Needless to say all the SVN "GUI" are third party components, try to get support from them to report issues or new features... good luck.

Refactoring, Subversion's Inaccurate management of moved, renamed and added files when integrating branches of code results in increased downtime, integration errors and reduced product quality. I guess that the refactoring support/transparent scm is another silver bullet than makes you loose time.

Installation and configuration, I challenge you to install subversion using a Active Directory and perform a basic cycle of branch&merge, of course I'll do it with Plastic. A beer for the first to accomplish it.

Evolution, new SVN features in the last 2 years? What about plastic?

Comprehensive backend database option, I rather prefer MySQL or SQL Server than Berkeley DB or the file system, big enterprises think the same.

Scalability and performance: Plastic SCM can consistently beat Subversion in ALL scenarios, including under heavy load.

Integrated security: Plastic SCM has integrated ACL-based security, something missing from Subversion.

I can continue spitting more and more comparisons all the morning but I think it's enough.

On the other hand, you are right, we don't support subtrees xlinks.

[CG]

@wnicholls

Ah, I think I understand your issues now.

I guess it really comes down to how you want to work. You could very easily put all your code in a single plastic repository (as you have it all in one repo now). In that case you wouldn't need xlinks. But that does get a little ugly from the workspace perspective. I guess you could create several different top-level branches (i.e. several "main" branches) and keep your code segrated in that way, but all in one repository (so different main lines for different customers). Then the workspace is clean again. And while I've never actually tried this, I suppose you could have an xlink in one top-level branch that points to a changeset in another top-level branch in the same repo. So in this way you could have your components shared with customer specific code branches and still be in one repo.

Again, though, that doesn't fix the problem with remapping subtrees.

However, remapping subtrees at the workspace level is out of the scope of the storage structure of the data in the repository--that's a local working level decision. So one user may choose to map things one way and another may map things in a different way. That information isn't stored on the server, so setting up links in this way (even using plastic v3.x) would require developers to all set up their workspaces in the same way (which gets away from the idea of having things nicely managed in your repo and allowing a dev to just pull down something and it just builds).

I haven't used subversion or git's subtree mapping, but my understanding is that's how it works--it's a mapping defined at the local user level, not the remote repository level?

If that is the case, you aren't missing anything, really, with Plastic v4.x. Since subtree mapping is a local developer choice and relies on the developer to set his map up the same as other developers, you can achieve the same result by using local operating system/file system tools. Not the best approach when coming from git or subversion, but it fixes the problem and still gives you all the benefits of Plastic.

For example, you could pull down your code using your previous example (from one repo or many) into three separate workspaces. Within each you could have a link/junction to another workspace at the level you need. And then in Plastic's ignore.conf file you could add the subtree as an exclusion. That way your developer tools still pick it all up and see it all as one structure.

Granted, that's very ugly, but in principal isn't any different than requiring developers to set exactly the same convoluted selectors in plastic v.3.x workspaces. In fact, a simple shell script could be built that creates the workspaces, folder structures, links, and pulls down the data from plastic in one "click". Again, it's ugly, and I wouldn't want to work that way.

It just really comes down to how critical that one feature is for you vs all the other benefits that Plastic offers. No tool is right for every scenario (unless you write your own for your specific use case)--there will always be some form of compromise. And while Plastic still lacks several things I would like, none of them are show stoppers for me. I mean sure it would be great to have xlinks to subtrees, but we've worked around that issue with a standard around our repo structures, versioning, branching patterns, and how things are linked. However, I find that the issues I have with Plastic that could be solved by another SCM are far outweighed by the benefits I get from Plastic and the things I'd lose by moving away from it.

With all it's capabilities (and despite it's current flaws), once you really get into using it, you'll never want to move to another SCM again--it's just so nice to work with, especially when using complex branching with lots of development occurring.

Another thing worth mentioning is that if you truly are looking for the capability to stay tool agnostic and be able to switch from one to another, you should probably stay away from complex setups involving thinkgs like subtree remapping (git, subversion) and xlinks (plastic) as then it just makes it that much more complicated to try and switch later (by using something like fast export).

[JakubH]

@Manu: I think you have misunderstand wnicholls now. "Silver bullet" was a big compliment actually. See http://en.wikipedia.org/wiki/Silver_bullet (Idiomatic usage):

"silver bullet" refers to any straightforward solution perceived to have extreme effectiveness.

[manu]

Well, my initial idea was that we were talking like "A new tool that's supposed to increase your productivity but it's, actually, useless"