Jump to content


Locking files across streams

streams

  • Please log in to reply
3 replies to this topic

#1 fwalker

fwalker

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 26 September 2019 - 01:34 PM

I know that locking files across streams was a feature request being considered in 2017. Has there been any progress on this? Any news on when this feature will become a reality?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1130 posts

Posted 27 September 2019 - 02:11 PM

By "locking files across streams" you mean having a single linear file history across multiple streams (with exclusive editing) to prevent any merges from happening, right?  That's been possible for a while via the import+ path.

If you actually had multiple branched variants, locking them all simultaneously wouldn't help you any unless you also atomically propagated every edit across all the variants as soon as it was submitted.  And at that point, it's no different from having a single depot file that's shared across all the streams, which is what import gives you, and import+ gives you the convenience (and drawbacks) of being able to edit it from the context of any child stream.

#3 QHovey

QHovey

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 20 December 2019 - 07:32 PM

I'm getting increasingly more frustrated with responses on this topic that boil down to "It's just like working directly in mainline".

I want my artists and designed to submit their work in progress to a task stream that can be reviewed by a lead. This is exactly how programmers work with code reviews and pull requests. The difference is that code can be continuously merged. Artists and designer's deserve to have a history of their work in progress just as much as the rest of us. They would get the added benefit of locking the file and thus never get a merge conflict. They can even merge the latest Mainline down and test their work in the latest game before submitting it up. It's all about the submitting to the task stream. Import+ would change the file on every stream as soon as it is submitted thus "it's just like working directly in mainline".

Anyway, it shouldn't take 3 years to implement a simple recursive function.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1130 posts

Posted 07 January 2020 - 04:17 PM

If you've been hearing that suggestion a lot and your takeaway has been "just don't version those files", the people suggesting this approach haven't explained it correctly.  :)  Files on the mainline that are never branched still have version history, but the difference is that the history is linear (i.e. you don't have branches that can diverge from one another and require merging -- something you'd want to prevent, yeah?).  

In a situation where a single file is branched to lots of other points but you prohibit the branches from getting out of sync (i.e. by locking across branches and propagating changes to all other branches before the lock is released, which is the only way to prevent conflicting changes), you also have a linear history, but with a lot of extra bookkeeping; the branching mechanism adds nothing because for all practical purposes the history is not allowed to branch.  Rather than try to add complex mechanisms to make it easier for a branched file to act like a file that is not branched (each of which will probably generate its own unforeseeable problems that will need increasingly complex solutions), the KISS solution is to not branch the file in the first place.

In environments where branching isn't possible (or desirable) but you still need to have controls on when a version is released, considered stable, etc, a standard version control workflow is to use some sort of "tag" (in Perforce this would traditionally be a label, but I've heard of people also using a client's have list or a counter that references a changelist, and in the modern era of streams we also have the option of versioned import paths) to represent significant versions (e.g. particular releases, or to denote stability or approval).  The difference between a tag and a branch is that a tag references a point on a line, whereas a branch creates a whole new line (again, that's the thing we want to avoid).

For work in progress that needs review, rather than a task stream I'd use a shelf (which is pretty standard for code review in Perforce anyway).  Artist opens the file, locks it, does work, shelves for review.  Lead unshelves the file in their own workspace, reviews/tests, gives approval.  Artist submits, and the new version goes in at the same time the lock is released.

You could also do this with a label-based workflow (in the days before branching, shelving, and continuous integration, people did this by incrementing a "blessed" label once a given version had passed tests), but locking gets a lot more awkward; the artist would need to reopen the file and hold the lock while waiting for the lead to increment the label, releasing it only after they're sure the new version has been approved.

"Merge the latest mainline down" becomes "sync the head revision of the mainline".  Merging is to a branch what syncing is to a workspace.

If a particular stream needs to have an old version of the file and you don't want to deal with using a label to track which version goes with which stream, you can do that with a version specifier on the import path.  Versioned import paths also prohibit submits, which handles the "stale branch" problem that the "recursive lock" solution fails at.

FWIW, if I were implementing this workflow I'd skip the import+ thing entirely; it probably doesn't make sense for artists to be working in a bunch of different streams given that they can't merge their work between them anyway; why should they even have to think about other streams when everything they're doing is in a straight line?  Instead I'd have artists work solely in the mainline stream, using shelves and locks to manage reviews and prevent conflicts.  Cut all the other streams with a versioned import of those files.   Once work is submitted to the mainline, any other stream (release streams, feature streams, whatever) can get it by bumping their version number to match the new version of the art they want to code against -- or if they want to just "float" at the head revision at all times, don't put a version number on the import.





Also tagged with one or more of these keywords: streams

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users