17 replies to this topic

[diegobowen]

Labeling in version 4.0 is completely different yes and as a result how is the migration of labels and there history addressed if you're migrating from version 3.0 to 4.0? The reason why I'm asking is because we recently exported/imported a 3.0 repository over to 4.0 but the labels were all messed up.

[manu]

Hi Diego,

yes the labels are quite different between 3.0 and 4.0.

In 3.0 you can apply a label a workspace content having revisions from tons of changesets. In 4.0 are not applied to a certain changeset thanks to the DAG structure.

So the relationship has been moved from 1 - n to 1-1.

That said, the labels migration are not an easy thing, so we have to go trough a compromise solution. The 90% of the cases the labels are mapped to 4.0 as you can see them drawn in the 3.0 branch explorer, in the other 10% are more difficult to handle.

Can you show us and example of one of your imported labels?

Manu.

[diegobowen]

Thanks Manu here you go:

The first screenshot is a Plastic 3.0 label content.

[diegobowen]

Here is the Plastic 3.0 label

[diegobowen]

here is the screenshot for the same label in plastic 4.0

[diegobowen]

It doesn't look like the screenshots attached so sending email to support codice

[manu]

Ok, I have the email!

[diegobowen]

Hello Manu, thanks for replying...so based on the screenshots I sent you would that mean that our label fall under the "10%" category? How are other companies handling this situation of labels not migrating over? What would you recommend? Thanks

[psantosl]

Hi Diego,


Well, I wonder what is the real use you give to those labels. It looks more like a way to group some files together. Do they belong to a different repository? Maybe splitting your codebase into smaller repos?

[diegobowen]

Moving forward that would be the way to go especially with XLinks however I have to maintain the code history in migrating our Plastic 3.0 instance to 4.0. Short of having two Plastic instances running, one with version 3.0 for prior releases etc and one with version 4.0. This option isnt really appealing since it buys into our h/w resources. Which is why I'm curious if other people are running into a similar issue with labels. Thanks

[diegobowen]

Actually this is a key road block in renewing our license can your support offer an acceptable workaround?

[psantosl]

Hi Diego,

Fortunately not a lot of people is running into the same issue with labels.

One of the key reasons why we (and all known DVCS out there such us Git, Mercurial, Bazaar and others) moved towards "changeset based" labels was:

• 99,99% of the time teams were labeling csets instead of individual file sets
• Applying the new labels is simply incredibly much faster than it used to be
• Overall, the entire system is easier to understand

That being said, let's try to figure out a solution for you:

• What do you use the partial labels for? Releases?
• Would it be possible to create a configuration on a branch matching a "partial label setup"?
• Are your partial labels just sub-trees? If so, maybe we can have a potential solution.

pablo

[diegobowen]

Hello Pablo, thanks for your response:

• What do you use the partial labels for? Releases?

Yes for releases.

• Would it be possible to create a configuration on a branch matching a "partial label setup"?

Please elaborate on this and what the ultimate goal would be for doing this...would it be a prelude for a possible work around?

• Are your partial labels just sub-trees? If so, maybe we can have a potential solution.

Yes. We have one repository with about 20 sub-directories. The labels reflect a component like approach in putting together a number of these sub-directories for a release. Moving forward with Plastic 4.0 I would like to move away from this in favor of having each one of these sub-directories be a repository. Where I create a repository containing all the release branches for each of these projects that I can then use Xlinks to link to specific repository changesets or labels for a release tag on the branch.

[diegobowen]

I am on PST and I'm planning on being in the office at 5AM Friday which I believe corresponds around noon at your time. Would it be possible to do a gotomeeting again to possibly resolve this issue? thanks

[psantosl]

Diego,

We will need to split the repo in parts, but this functionality is planned but not yet there. We could replicate to 20 different repos and then delete the remaining parts, but doesn't sound so good. We'll have to think on it and try to come up with a solution for your scenario, it is not evident.

If you need more specific support, please contact us to the support email, this case seems to exceed forum purpose.

[diegobowen]

Thanks I'll send a support email capturing all this and ping you Friday afternoon. Thanks

[diegobowen]

Hello there, Pablo, you made the following comment above and I was wondering if you might elaborate on it please?

That being said, let's try to figure out a solution for you:

• What do you use the partial labels for? Releases?
• Would it be possible to create a configuration on a branch matching a "partial label setup"?
• Are your partial labels just sub-trees? If so, maybe we can have a potential solution.

pablo

[diegobowen]

I'm particularly interested in hearing about your potential solution for how labels where used to partial label sub-trees for releases since in Plastic 4.0 you can no longer apply labels to files. Thanks