Settings and activity
33 results found
-
65 votes
An error occurred while saving the comment An error occurred while saving the comment 
Max Pixel
commented
I've discovered another sour aspect of this dysfunction: Merging.
Scenario:
Artist changes "Foo" on "art" branch, checks it in alongside "Bar"
Artist gets feedback and starts modifying "Foo" again, checking it out
Developer needs "Bar" in order to do their work, so they try to merge from "art" to "dev"
But it doesn't work - the merge contains a revision to "Foo", and "Foo" is currently checked out, so the merge fails.The merge shouldn't fail, because it's not actually creating a new revision of "Foo" - it's carrying over an older version. Plastic has no reason to think that "Foo" will be modified as a part of the merge, because it's "changed on source only, no conflict".
My team runs into this every other day. It happens increasingly often as we move from "building new features" to "revising existing features" - a situation where, ironically, exclusive checkout is even more important. In order for developers to not be completely blocked by checkouts that have no logical reason for blocking their needed merge, we need to either check-in prematurely, or shelve changes (in the case of Gluon users, this means copy to desktop, then unco, then move back from desktop after coworker has finished merging).
It's a major waste of time, and we're starting to question if maybe it's a bigger waste of time than running into conflicts, or doing exclusive checkout manually through something like a Google Doc of "who has what".
Max Pixel
supported this idea
·
An error occurred while saving the comment Max Pixel
commented
I'm in strong support of this. This highlights a serious flaw that objectively cripples the lock system. I hope that the misinterpretations in the comments don't hurt the chances of this becoming a feature. I'll try to clarify even more. This is even more important for UE4 where Blueprints are even less mergeable than Unity assets.
The way it currently works:
1. Alice checks out Foo.uasset on branch main/A
2. Bob cannot check out Foo.uasset because it is locked
3. Alice checks in Foo.uasset on branch main/A
4. Bob can now check out Foo.uasset on branch main/B, which he does
5. Bob checks in Foo.uasset on main/B
6. Admin tries to merge branches A and B into main, but there is a merge conflict for the unmergeable Foo.uasset - why did we even bother with locks in the first place?How it SHOULD work:
1. Alice checks out Foo.uasset on main/A
2. Alice checks in Foo.uasset on main/B
3. Bob tries to check out Foo.uasset, but it fails because it has been locked on a revision that is later than the revision of branch B's current Foo.uasset
4. Bob merges main/A into main/B, or cherry-picks the changeset where Alice checked-in Foo.uasset.
5. Bob can now check out Foo.uasset, because the Foo.uasset *revision* on *his* branch corresponds with the *newest* *checkout* of Foo.uasset on *any* branch.In essence: When you check out a lockable file, it should prevent others from checking it out until they have updated to your check-out's corresponding check-in.
-
108 votesMax Pixel
supported this idea
·
-
102 votes
An error occurred while saving the comment Max Pixel
commented
"Now, let’s follow the rule we all use: checkin with the reviewer in mind. Every checkin has to help the reviewer follow your train of thought, follow your steps to understand how you tackled the task.
First, you see 21 files modified, but the comment says it was just about cleaning up some C# usings. The list of 21 files is not terrifying anymore; it is just about removing some easy stuff. You can quickly glance through the files or even skip some of them.
Then, the next 12 files are just about a method extracted to a new class, and the affected callers having to adapt to the new call format. Not an issue either.
Next comes 51 files, but the comment clearly says it is just because a method was renamed. Your colleague is telling you it is a trivial change, probably done thanks to the IDE refactoring capabilities in just a few seconds."
This absolutely great idea from the Plastic Book is less attainable without amendments, and extra difficult without the ability to stage individual lines (index vs head). You can tell a better story with a single "removed unnecessary usings" commits than with three that are spread out over your working session. Professional writers don't go top to bottom in a single pass - articles are revised. "Telling a story with my commits" is the #1 thing that I use Rebase for in Git. Plastic forces you to tell that story the same way you would if you were thrust in front of an audience - "actually, wait, I forgot something, let me go back a step..." is not as easy to follow.
Sometimes I'll change my mind multiple times throughout developing a feature as to how a certain class should be named. History amendment helps clear that up. The arguments against history amendment are sufficiently addressed as long as amendment is only possible for changesets that haven't been pushed yet.
Max Pixel
supported this idea
·
-
7 votesMax Pixel
supported this idea
·
-
3 votesMax Pixel
shared this idea
·
-
5 votes
An error occurred while saving the comment Max Pixel
commented
This would be very useful for document repositories. Currently, I have several single-file repositories, one for each document that should be branchable/instantiatable, which ends up being a bit kludgey (but still better than no version control or branching at all).
repos:
documents
documents/contracts (empty)
documents/contracts/MNDA
documents/contracts/vendorfile tree:
contracts/
____MNDA/ (xlink to main@contracts/MNDA)
________MNDA.docx
____vendor/ (xlink to main@contracts/vendor)
________vendor contract.docx
client/Contoso/
____vendor contract for superapp/ (xlink to Contoso@contracts/vendor)
________vendor contract with Contoso for superapp.docx
____MNDA/ (xlink to Contoso@contracts/MNDA)
________MNDA with Contoso.docxThere are a lot of unnecessary folders for single files. If I could xlink a single file, it would be a lot cleaner, and I could have just a single repository for the templates.
Repos:
documents
documents/instantiatablecontracts/
____vendor contract.docx (xlink to main@instantiatable)
____MNDA.docx (xlink to main@instantiatable)
client/Contoso/
____vendor contract with Contoso for superapp.docx (xlink to Contoso@instantiatable)
____MNDA with Contoso.docx (xlink to Contoso@instantiatable)Max Pixel
supported this idea
·
-
7 votesMax Pixel
supported this idea
·
-
2 votesMax Pixel
shared this idea
·
-
16 votesMax Pixel
supported this idea
·
-
2 votesMax Pixel
shared this idea
·
-
1 voteMax Pixel
shared this idea
·
-
42 votes
An error occurred while saving the comment Max Pixel
commented
This would greatly facilitate Plastic's advocated practice of making task-branches with changesets crafted to tell the story of the task's development.
Max Pixel
supported this idea
·
-
46 votesMax Pixel
supported this idea
·
-
3 votesMax Pixel
shared this idea
·
-
50 votesMax Pixel
supported this idea
·
-
93 votesMax Pixel
supported this idea
·
-
122 votesMax Pixel
supported this idea
·
-
1 voteMax Pixel
shared this idea
·
-
3 votesMax Pixel
shared this idea
·
-
6 votes
An error occurred while saving the comment Max Pixel
commented
While you're at it, might as well do the same for `cm unlock`. If I `cm unlock 168ffbb4-ef54-4ee4-af4d-0dfd97050b1b`, and that GUID exists in the repository `assets`, and `lock.conf` contains `rep:assets lockserver:ServerA:8084`, then I expect it to actually do something. Instead, it does nothing, because nothing is locked on my local server. I am required to run `cm unlock ServerA:8084 168ffbb4-ef54-4ee4-af4d-0dfd97050b1b`
Max Pixel
supported this idea
·
Perforce has the same problem. UE4's Perforce integration solves the problem by preventing you from checking out any file that has a newer version in a different branch (through the editor interface, anyhow, you can still check out such files in P4V or via the command-line).