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).

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.

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.