We keep on gradually improving git LFS file locking feature. In Bitbucket Server 6.4 we started to show lock icons against filenames on Source view and Source listing pages to help you spot locked files easier. 

Source listing:

Source view:

To learn more about new features in Bitbucket Server 6.4 visit Release notes.

Cheers,

Anton Genkin
Product Manager Bitbucket Server

morten.stensgaard

Bitbucket Server (previously known as Stash) was first released in May 2012 as an enterprise-grade, high performance, self-managed Git repository hosting and collaboration tool. It was built from the ground-up for self-managed deployment.

Bitbucket Cloud was acquired by Atlassian in 2010 and was purpose-built for the multi-tenant public cloud. As a result, Bitbucket Cloud and Bitbucket Server has different technical architectures with different feature roadmaps. 

morten.stensgaard, you could vote for #14454 - Git LFS (v2.x) File Locking Support in Bitbucket Cloud.

I Assume Bitbucket Cloud is a customized version of Bitbucket Server behind the scenes

IIRC, someone from Atlassian mentioned that Bitbucket Cloud and Bitbucket Server do not share any source code. The Wikipedia article on Bitbucket says they are even implemented in different programming languages (Python vs. Java). Bitbucket.org was originally a separate company that Atlassian then acquired.

Does anyone know, when/if new features like this are released on Bitbucket Cloud? (I Assume Bitbucket Cloud is a customized version of Bitbucket Server behind the scenes - But is it behind/infront on release versions?)

Good news.. Thank you Anton

Woohoo!  

Totally need a firework here!

Hi everyone. I'm happy to announce that Bitbucket Server 6.3 has support for Git LFS file locking!

You can now lock files stored in LFS to avoid merge conflicts. Please read the docs to learn more about locking and unlocking - Working with Git LFS Files  and don't forget to share feedback on the feature. We are keen to learn if there are any areas of improvement.

To learn more about new features in Bitbucket Server 6.3 visit Release notes.

Cheers,

Anton Genkin
Product Manager Bitbucket Server

Any update on this?

Anton Genkin you posted a duplicate issue of https://jira.atlassian.com/browse/SRCTREE-4663 so that is where votes should go.

cheung.waiho975291557 thank you for pointing at the permissions problem. It solved now and I hope nothing else will stop you from taking the survey.

Hi Anton,

I dont seem to have permission to enter your survey.

Thanks,

Hi everyone. As the team moving forward with git LFS file locking we'd like you to tell us more about your context. Please take a 30 seconds survey to help us ship better LFS file locking experience - https://goo.gl/forms/gFstknvbwC76C8bc2

–

troscoe, we're discussing with SourceTree team ways to align on the LFS file locking. I can't share the details with you right now, but if you're interested I suggest you vote for the feature - SRCTREEWIN-4663

Can you please roll this out?  This is super important for our Creative team working with Adobe files (which are binary) and the Reporting team with SSRS reports, which are not awesome for branching and merging. Your competitors already have this functionality, please give this a priority of sorts.

If an application allows modification of a read-only file, it is the fault of the application and either a better application should be used for editing the file or the application's behavior can be cusotmized through scripts or an improvement request can be submitted to the application provider.

Moreover, it is possible to modify the editing application to trigger a locking event when a file starts being edited and warn if the lock was not obtained.

As for the best file locking strategy; it is true that a centralised architecture can have the best locking feature (with the associated downfalls) but even with the distributed nature of Git, it is more than possible to have a pretty robust locking workflow.

@benoit37 i disagree on that, i looked at Git LFS locking and it does not help the user avoid working on a file that is locked.

If work has been done on a file which is read only (which is obviously possible) its already to late by the time the user wants to write the file.

Not to mention that the user needs to actively pull the specific file-lock to even be able to see it and there is a fight going on in the windows icon overlays so you will most likely not even see the locked icon due to other icons taking up the rare spots.

As stated before i do not see how a real file lock is working without a centralized server solution which seems to be the way to go for proper file locking.

@Daniel Grauer , no such functionality is needed with Git LFS locking design.
You see, file types that are flagged as lockable become read-only when they are not locked, so it is not possible for a user to make any change on them without locking the file first.
If the file is already locked by someone else then the user won't get the write access and wont be able to do any change to the file.

agenkin thank you, you've made my day! And please keep us posted on the progress of things.

@Anton Genkin thats great news!

However i was wondering how you implement the functionality that the user sees that the file is locked before he gets to work on it. If one works on a file and sees the lock afterwards then the lock is useless and manual merging of binaries will still be the norm.

Since i have not seen any details in this ticket about how this issue will be addressed and i hope you are developing it in such a manner i wanted to ask if that is really the case or if you are implementing the standard git locking which does not consider this important issue.

Great news Anton, do you have any insight into whether or not there are plans to extend this to sourcetree? This feature is ideal for less technical users who work with large files and need the ability to lock them while they update. So something like a simple "right click"-> lock (pull and lock) and -> unlock (commit and push) in the UI would be amazing.

sergei.titarenko No reason to search for an alternative, because I have good news for you and everyone else who is anxiously waiting for git LFS file locking API. The team has just started to work on the feature. You can expect it to be released in one of the upcoming Bitbucket Server releases.

Hi all non-Atlassian folks who were watching this issue. It's been a year since this core functionality is sitting under small-improvement label in Under Consideration status while the devs are happily adding unicorn emojis. I'm sure most of you have lost faint feeling of faith that Bitbucket will ever be supporting file locking API. Can anybody here give recommendations what is better moving to [_moderated myself here to remove mention of competing products because we have faith in Atlassian now_], or there are other competitive solutions? Thank you

@Roger Barnes I think we all get the position your team is in, but it is frustrating from the user perspective to stub our toe on something in your tool, only to find that it's a known issue and was found several years ago by other people. 

The line about customer prioritization gets a little old when Atlassian has things like BSERV-10710 adding unicorn emojis next to implementing BSERV-9623 a modern feature of GIT.  It is frustrating for both sides I'm sure, but some better communication would really help.

mobrie12, bugs don't tend to gather votes (we like to fix them), so best to exclude them. Taking only suggestions into account, 55% have 10+ votes. Beyond that, I take issue with various assumptions in the analysis that I'd prefer not to distract myself or the team further with.

Votes are not the only prioritisation input we use, others include customer interviews, customer panels, customer surveys, customer events, customer analytics, customer ... you get the idea, customer input generally is the primary factor, but votes != customer demand. We also don't use jira.atlassian.com like a typical software project. It's simply a public record of which suggestions and bugs are open, and a place to discuss them. So you'll rarely, if ever, see assignees, fix versions, etc. I mightily wish sometimes that we didn't use Jira for tracking product suggestions for the unintended expectations it sets in some people's minds, but I digress.

As a guide, our roadmap typically refers to a 6-12 month timeframe. Plans can change, but I hope that helps as a guide.

> Is there a possibility that if LFS locking is ever implemented, that it will be a Datacenter only feature?

No.

Since Atlassian posted stating that this highly voted on request is a priority and is on their road map (but cannot share their roadmap plans whether for tomorrow or next year), our only option is a review of what the past year's (2018) Atlassian roadmap has delivered... [see last years review (of 2017) in comment dated 05/Jan/2018 5:20pm]

• Of the 185 Bitbucket server issues requests resolved in past year (down from 249 resolved issue from previous year):
  • (69%) 127 have only 0 or 1 vote
  • (91%) 169 have only 10 or less votes
  • Only 16 have more than 10 votes (actually only 15)
  • Only 5 have more than 100 votes (actually only 4... which seem like real soft balls... updated search, add watchers, etc..)

Why the -1 above? The kicker here is that the one bitbucket server request completed with highest number of votes (BSERV-4586) and highest relative value to customers, the ability to export and import projects/repositories, was made available in datacenter only. Seriously, what customer focused analysis resulted in that decision. Is Bitbucket server becoming a 2nd class citizen?

So roughly 8% of completed requests (down from 10% last year) align with issues with a customer demand of more than 10 votes (assuming atlassian employees dont vote on the customer facing JIRA). With such a small percentage it may be likely that even the 8% was not driven by customer, more likely it could be that the 8% was just random overlap from the planning criteria which selected other 92% as well. 

• Of the 1663 bitbucket server issues currently unresolved issues, which have been updated in past year:
  • (52%) 873 have only 0 or 1 vote
  • (84%) 1402 have only 10 or less votes
  • 261 have more than 10 votes (up from 166 last year).... but none have been assigned a fix version
  • 35 have more than 100 votes (up from 26 last year).... but none have been assigned a fix version (LFS locking is in this group, currently #4 rank in votes)

It looks like Anton Genkin updated this issue for Imran Khan (sig'd as a Bitbucket Datacenter PM). Is there a possibility that if LFS locking is ever implemented, that it will be a Datacenter only feature? (Seriously, this has happened before to highly voted Bitbucket "Server" request)

<<Resolved by Votes filter>>
statusCategory in (Done) AND resolution in (Done, Fixed) AND project in ("Bitbucket Server") AND resolved >= -365d ORDER BY votes DESC

<<Unresolved by Votes filter>>
(statusCategory in ("To Do", "In Progress") OR statusCategory in (Done) AND resolution in ("Won't Do", "Won't Fix")) AND project in ("Bitbucket Server") AND updated > -365d ORDER BY resolution ASC, fixVersion ASC, votes DESC, updated ASC 

My users are making me pursue hacky and unsupportable alternatives to this... please just implement this so all of us admins can move on to other things.

Hi! Just wanted to add my voice to those requesting this feature. We also have a high need for this feature, for sharing Enterprise Architect Project (.eap) files.

We didn't have this issue before, since we used SVN, which has a lock feature. But now that we have migrated to Git, we are having lots of trouble editing .eap files from different locations. Merging this type of files can be hell and is not an option.

Therefore we request that you please roll out this feature as soon as possible!

Hi Imran - having a rough idea would be handy. One of my product teams is asking for a workaround and not knowing when Atlassian would do this meant we were about to schedule some time to develop something using Scriptrunner. Are we talking 1 month, 3 months, 6 months, a year, 2 years or 5-years? If it's this quarter, then I'll tell my guys to wait and suck it up for a while

Hi r.wayne.craft

This is on our short term roadmap. We will share more concrete details on the timeline when we have cleared some blockers (especially with making it work over ssh). 

Cheers,

Imran

hey guys, things seem to have dropped off with this again. it sure would be nice to receive another update based on the product road-map that was referenced in the post by Imran Khan in July 2018. For now we are forced to work in split repos between Bitbucket and SharePoint. Can anyone from Atlassian provide an update?

I agree with Andrew. It can be something as simple as a Microsoft Word document (which is really a zip file with a bunch of xml inside). There are plenty of reasons to check these kinds of files into the repository. They can't be merged effectively, so some other mechanism needs to be in place to single-thread the changes.

@morten Often times it's not the culture, it's the technological need. For example SSIS and many other file formats are not merge-able, they must be treated as binaries. Locking simply provides a communication point to another user that may try to edit the binary file, that someone else is working on it. It's not contrary to AGILE, or any modern development concept, it's simply a pragmatic technological necessity.

Yep same issue here - The method of file locking is somewhat stupid but needed. Currently trying to migrate away from SVN and TFS - but having same culture reluctance around habits for doing file locking.

For one of our major projects (several hundred users), we've been evaluating bitbucket. Really love it BUT without this feature, it's likely they will go with SVN (because it's what they know). To get this close to convincing them and then fall at the last hurdle would be disappointing. Can you at least give us a timeline as to when this will be done?

File locking is needed ASAP. Our SSIS development team needs this feature and is sticking to TFS until this feature is available in Bitbucket.  Your competitors already have it implemented, so please make it easier on Atlassian evangelists out there, provide file locking. This can't be that hard.

Hi everyone, 

Thanks for voting and commenting on this suggestion. Your input in the comments helps us understand how this affects you and what you're hoping to accomplish with Bitbucket Server. This suggestion is a priority for the Bitbucket development team and is on our roadmap, however we're not able to provide a timeline for when it will be resolved. I'll keep you posted. 

Cheers,
Imran Khan

Product Manager - Bitbucket Server and Data Center

We have around 1700 in development and are in need of file locking especially for un-mergable binary LFS data. Most of our folks are still using SVN but are about to switch to something else this year. There is a small pioneering group that is putting a lot of effort into migrating all teams to Git & Bitbucket but they are stuck with this problem of missing a very basic function. I'll give it a few more months to see if there is any reaction and progress from Atlassian and will also start to consider switching my team to Perforce. 

One of our teams is already moving to Perforce because Bitbucket does not support this. How frustrating as an administrator...

Most use cases don't need this feature, so "let the money talk" would perhaps be exaggerated or if accurate, uncompelling. I speak for 2500 users as well, and I want this feature as well, but if I'm being accurate about our requirements, most of these 2500 people either don't need this feature, or it would only be useful for a subset of users in a subset of cases.

I think the more compelling case is "shame" and "competition". When new features such as Git LFS were first introduced, there was a great deal of buzz about Atlassian being a part of this specification with GitHub. However, I believe Atlassian's server side implementation of LFS was very late, and server side implementation of features like LFS Locking are still very late. Also, to this date, we're still implementing a hack on the proxy server to allow Git LFS to properly interact with Bitbucket, because they not only don't implement LFS Locking API, they also don't implement the stub that will say "Not implemented." Bitbucket responds with "Not authorized" which encourages Git to try again rather than abort. The latter was a few lines of Nginx for us to do what Bitbucket should already be doing natively.

I believe Git LFS Locking API (in its early form, anyways) is implemented by:

• GitHub
• GitLab

Anybody who needs these features, should target a solution which meets their requirements.

But more than this, if Atlassian is really part of Git specification and development, I would like to see Bitbucket as a leading implementor of the specification. This is the real proof of who is leading this industry, and who is following. Not any single feature - but looking at the top 10 features that are core to the platform, including emerging features like Git LFS Locking API - the product that releases these the earliest, and in the best state, are the industry leaders, and the people who release it late, and with missing functions, are the followers. Atlassian: Are you the leader or the follower here?

We have 2500 licenses and growing - but this is limiting our full adoption of Bitbucket - considering other options now.

Let money talk!

400 employees need to lock their files!

Over 30 users here.

Let the money talk.

Over 100 users here.

Money is always a good motivator, we should include numbers in our comments to help atlassian decide.
For example, we are now 450 employee that would need licences for bit bucket but we’re not because of the lack of locking.

At this moment GitLab has file locking feature and we are thinking about migration because there is no feedback from Atlassian.

However, as of now it is actually the 6th most voted issue on Bitbucket Server.
See here: https://jira.atlassian.com/projects/BSERV/issues/BSERV-9623?filter=allopenissues&orderby=votes+DESC%2C+priority+DESC%2C+updated+DESC

It would be nice to get some information from the product managers on this issue.
Maybe get an indication of when it will be part of the product road map?

I don't think this will get done - it's close to 1,5 years old, unassigned and tagged with "small-improvement" which has things like "old icon in installer"...

Nothing yet? Would be a neat feature!

Bump, any progress to start considering this feature support seriously?

Hello again. Is there any expectation to implement this feature? Thanks.

This is a necessity for several functional groups in my organization and is blocking them from transitioning from our previous VCS to Git.  Hopefully this gets added to Bitbucket soon, and file locking can be done through the web UI.

Additionally, this is also blocking my organisation from moving a project from SVN to Bitbucket Server as they require file level locking for particular files that can not be merged. This is causing pain as the project is split between the 2 source control systems.

Locking files is a MUST HAVE feature for us! We work on Oracle ERP and part of our development creates binary files (screens, reports, etc.). Merging these files is almost impossible. We're currently leaving our VCS (Synergy IBM) as it's unsupported already, and looking for the new tool, and the only thing that prevents from us to start using GIT and Bitbucket for our purposes is the fact that locking files is missing in this solution. So please add this feature ASAP!

Thanks.

Please make sure, if you are commenting on this issue, that you are voting on it as well! its good to see this transitioning to "under consideration". this is much needed for many organizations!

The same is true for Microsoft MFC ressource files (resource.h and *.rc). Well, they are text files, but in general they are very difficult to merge. We would appreciate this feature.