Update workspace with pending changes

[pysnoo]

Hello, I read this thread :

 

This is exactly what I'm trying to do but even with setting "Allow'" in Preferences/Other options and "Allow to merge with pending changes" in Preferences/Diff and merge" I can't do it.

In my situation, if I choose "Update workspace" in "Items in workspace", it does nothing.

If I choose "Switch workspace to this changeset" by selecting next changeset if the graph, it shows me an error.

What is the correct process please

 

[psantosl]

Hey,

You set "merge options" but the message you are getting is about update.

Do the following:

* Go to pending changes.

* Select your changed files and right click "apply local change" (this will mark the files as checked out).

* Then go to the items view and click "update" => you should be allowed to move forward.

 

Plastic is doing all this to prevent weird scenarios to happen while working on the same branch.

[pysnoo]

Thank you for this answer but it is still not working.

 

All my files in pending changes are Checked-out.

When I click "update" in items view, nothing happens and I am not at the latest changeset.

When I click "switch workspace to changeset", it asks me to resolve pending changes (by undo or checkin).

[manu]

Hello @pysnoo that is probably happening because your workspace is tied to a changeset. Your GUI will look like like this: (probably)

When you switch to a changeset it's because you want to load that static configuration forever. The update operation will not take the latest changes from main, it will try to load again the changeset you are switched to.

You have two ways to easy your workflow:

1) The best one is switching your workspace to branch and not to a changeset, your GUI will show something like this instead:

And your problems will disappear.

2) If you keep working switched to a changeset you can enable the Pending changes view preference called "Look for newer changes in the repository" this will search for new content and will allow you to update or merge depending on your local changes. You will see something like this once there are new content created on the branch head:

 

I recommend you the option #1, it's easier and more natural.

Hope it helps!

 

[Chris Payne]

I have exactly the same problems and I am already on a branch, not a specific changeset.
I also have "Allow to merge with pending changes" enabled, but it still won't allow me to update.

[Alexis]

Hi, I'm having the same issue as @pysnoo even with the option in preferences and being on the branches. It works when the file status are "changed", but not when they are "checked-out".

Are there any advantages to checking out ? 
If I have checked-out files, Is there a way to automatically created a shelve with my changes when I attempt to change branch ? 

I'm just looking into ways to accelerate our workflows. I'm coming from Perforce and changing the state of your project while keeping your local changes is very simple and useful there. 

[calbzam]

Hi @Alexis,

Could you let us know more details of your workflow? Are you follow a branch per task workflow? Why do you need to switch the branch if you have checked-out items?

In this case, you will need to shelve/checkin the items before the switch.

Even if you don't have chked-out items but just locally changed items, we need to be careful when switch to different branch because the following error could happen:

https://plasticscmsupport.zendesk.com/hc/en-us/articles/360014970894-The-parent-revision-of-the-item-is-inconsistent-with-the-loaded-one-in-changeset-cs-xxx

Regards,

Carlos.

 

[Alexis]

Hey @calbzam, thanks for the quick answer! Here's a bit more details about our workflow using Unity.

We do try to follow the one branch per task workflow. In the past, on perforce, It was useful to have a changelist with some local changes specific to me that accelerated my workflow. For example, I had local changes made to the shared parameters file to boot the game without some features to accelerate testing just on my workspace. In Plastic, If I have that changelist, I need to shelve it, change branch, then unshelve every time even though there are no changes on those files. If this is unavoidable, we might be able to have a workaround in Unity by not having this file on version control, but it's useful to have it there for other members that don't play with this game parameter file.

Another thing that happens is that some plugins we use modify some files pretty often, either by cooking elements or by saving meta files. I'm guessing we could avoid this being an issue by not checking out those files ? I'm not 100% sure what's the difference between a "changed" file and a "checked-out" file either.

We're new with Plastic, please let me know if there is something I'm missing! So far, our tests with Plastic are going well, there's just those small frictions that probably come from our habits of previous version control softwares

Alexis

[calbzam]

Hi,

If you have some files with changes that you don't want to checkin the changes, you can add them to the hidden changes list or even remove the files from version control.

In a regular Plastic SCM branck per task workflow, you create the task branch before start performing changes on the files.

The main difference betweek locally changed and cehked-out is if you have enabled locks, the second option with lock the item for you.

Are you using the Unity plugin? It should ease the workflow with Unity projects.

Regards,

Carlos.

[Chris McElligott Park]

Hey, new to Plastic SCM, trying it out for a new project.  Been mostly using SVN over the last 17 years, although some git, and prior to that had been using some gross old stuff like Microsoft VSS and CVS in professional contexts.  Most things in Plastic make intuitive sense, but a few things are not clear.

Incidentally, I haven't seen the concept of checking out files since about 2004 (when SVN appeared, I ditched VSS for that), and I immediately recognize the utility of that for prefabs and other binary files.  I'm really pleased to see that exists as an option.

So, just some slight growing pains -- 

I am pretty confused by this issue with not being able to update just because there are some local changes -- that seems like the very definition of what a merge is for, and I don't know who would not want this to happen. 

Right now I'm on a basic scenario with the main branch, and I do have the settings option "Allow Merge with Pending Changes" on (I'm really not sure about the wisdom of that being off by default, but you folks do know your users better than I do), and I just click "Update workspace," which should pull down any newer files that are also on the main branch... merging as needed, or complaining of conflicts where it can't automatically do it... right? 

But instead it just tells me it can't do that because I have pending changes (I do -- there are three files I'm still working on, and that should be irrelevant to anything.  I don't wish to check them out, or have to create a new branch for what I'm doing with them; I recognize the power of being able to, but being forced to seems strange).

It feels like I'm missing something for a pretty simple use case here.  For example, I'm thinking about when our artists arrive on the scene.  They will frequently need to get code updates, but they'll have some local pending changes with whatever their current art is. Yes it is something they might want to do a checkout on if it's a prefab-like situation where someone else might edit the same thing... but if it's something they are responsible for and nobody else has any reason to go there, then I don't see why we'd want to force them to do a checkout on something.  They might just be experimenting with some local changes they plan to revert, and having to do a checkout for that sort of workflow just slows it down.

Been using plastic lightly over the last week, while still mostly focused on another project that is in an svn repo and which is winding down, and this is the first stumper I've run into, so that's actually really nice.

[Chris McElligott Park]

Ah, whoops -- there is a second setting in there under merge, which is the default behavior when there are changes.  It's set to disallow, but has options for warning (seems like should be the default at worst), or allow.  Changing it to allow, it works as expected.

I guess it doesn't bother me too much, because my team size for this project is going to be under a dozen people anyway, so it's relatively straightforward to manage.  But I'm curious why the defaults are not to just allow, frankly.  Is there some sort of risk of work loss that is possible that I am not used to?

When it comes to doing an update in SVN and there are local changes, the absolute worst thing that would happen is that there's a merge conflict that I then have to resolve prior to doing something else.  But that's not really a scary case, and it's moderately rare (mostly just affects people who happened to change the same line as someone else, or are both working on the same binary file).  Either way, letting them know sooner than later that there has been a conflict is good. 

For example, I do recall a time a couple of years ago where two people edited a prefab extensively at once (and now in Plastic this would be a "you should have checked that out first" situation, but that doesn't exist in SVN).  But let's suppose we have two someones using plastic who both want to edit the same prefab, and neither remembered to do a checkout first (shame).  I'd think that a merge failure message sooner than later is actually just what the doctor ordered, because otherwise you're risking them continuing to work and lose more and more.  Already at this point, they're going to have to figure out what their changes were, then write those down, then probably make a copy of their working version just in case, then revert the conflicted version to be what is on the main branch, then check that out, then recreate their additions and create any new ones, then commit their changes and check it back in when they do.

I can think of a couple of places where the most effective workflow would be blocked by the Plastic SCM defaults right now: having copied their local prefab so they can do side by side comparisons might count as pending changes that block the update function; and the initial update would not actually work to begin with, so they wouldn't find this out until they are ready to commit.

In general, I tend to encourage staff to do a full update prior to doing any commit, so that if there are merges that happen, they get all of those prior to trying to send data (and thus potentially impacting others).

There must be a reason why these are the defaults, and I'm worried it's because there's some sort of data loss in the merge conflict case.  If that's not the case, then I submit my example above for a great (and real) use case of why Allow (or at worst Warn) make for a better default for your users.  In my organization, I can just instruct people on alternate defaults when they install things, but I'd also just rather contribute to Plastic as a community since it is newer on the playing field.

[calbzam]

Hi,

- If you are using the Plastic GUI, the basic unit is the changeset (similar to git) and the default workflow is the branck per task workflow (you create the task branch before start performing changes on the files).  The workspace is always pointing to a specific changeset and you cannot update/merge indiviudual files but changesets. This design makes the merge performance in Plastic/git much better than other SCMs.

Even if you don't have cheked-out items but just locally changed items, we need to be careful when switch to different branch because the following error could happen:

https://plasticscmsupport.zendesk.com/hc/en-us/articles/360014970894-The-parent-revision-of-the-item-is-inconsistent-with-the-loaded-one-in-changeset-cs-xxx

- In the scenario you are mentioning I guess both developers are workinng on the same branch. This fits with a Gluon workflow (not Plastic GUI). Gluon is the GUI designed for artists or developers working with binary files.

In Gluon, the basic unit is the file (similar to SVN). The workspace structure is more flexible. You can potentially update/load items from different changesets. If you forgot lock/checkout an item and there is a conflicts, Gluon will be able to resolve the merge conflict for this specific file.

More details in the following blog post: https://blog.plasticscm.com/2019/10/incoming-changes.html

Please let us know if it helps.

Regards,

Carlos.

 

[Chris McElligott Park]

Hi Carlos,

Thank you for the clarification.  It looks like, based on the first article you linked, that the following happens:

1. I'm on version 500 of foo.c, and I start making changes to it on lines 20-22.  My working copy is now tracking this.

2. Elsewhere, version 501 of foo.c is checked in, with a bugfix on line 45.

3. I hit update on my workspace, and rather than detecting this discrepancy between my local copy and version 501, it just leave my working copy alone.  So the bugfix on line 45 is lost, but the changes on lines 20-22 are preserved.   It doesn't tell me about this, and I have no real way of noticing.

This is extremely perplexing to me.  Maybe I'm just too rooted in my svn way of thinking, but when there are changes to foo.c in my local working copy as well as in an incoming update, I expect those to be merged.  If someone else also changed line 22, then I expect that file to be in a conflicted state in my local working copy until I manually review it.

I really don't understand why things would be done this way.  Speed is mentioned, but we're talking about a client-side process where we only have to look at files that are changed in the working copy as well as in the incoming update.  I've never really had much of a performance issue with svn, even on projects with 25 GB in source control.

Even if we flip this around and do a commit with changes in it, we have to solve for this exact same problem in reverse or else there's really no merge capabilities at all.  This seems really inflexible to do it one way but not the other, and it seems like a critical missing piece of functionality to skip doing it both ways (I don't think that's where we're at).

[calbzam]

Hi,

In modern SCMs we need to think as changeset/commit like the basic unit. So you are not merging single files but changesets.

Quote

 

1. I'm on version 500 of foo.c, and I start making changes to it on lines 20-22.  My working copy is now tracking this.

2. Elsewhere, version 501 of foo.c is checked in, with a bugfix on line 45.

3. I hit update on my workspace, and rather than detecting this discrepancy between my local copy and version 501, it just leave my working copy alone.  So the bugfix on line 45 is lost, but the changes on lines 20-22 are preserved.   It doesn't tell me about this, and I have no real way of noticing.

 

Following these steps, if I try to update my workspace and this update involved a file conflict, Plastic will detect it and it will propose you to run a merge:

Resolving a merge is not a problem as soon as you are working with text files.  files

 

Regards,

Carlos.