Because of the way my repositories are set up, I am forced to pull from one location, and push to a different one.
SourceTree is configured in a way that causes me to get the following error:
"abort: Permission denied: /../../../.hg/attic"
Is it at all possible to disable hg attic from within SourceTree?
I was pulling from a shared repository. To me (I may be off-base on this), it felt as though SourceTree was trying to locate the attic directory on the repository I was pulling from, but because that directory didn't exist, it gave me the permissions denied error.
Unfortunately (because of the way our repos are set up), I'm forced to pull from a shared directory/file-system, and push via https. I'm not entirely sure this is why I'm getting the attic error, but I do know that our pull/push methods are somewhat unorthodox.
Is there any way to get around the permissions issue with attic?
Pull doesn't try to pull attic data (I just did a couple of tests to prove that, neither clone nor pull tries to sync attic entries).
However, I did notice that in each repo the .hg/attic folder only has read-access for anyone except the original owner. Even though no attic data is pulled, it may be that if your local repo's attic folder was created by someone else, that you don't have access to write to it and that's just getting picked up in one of the standard system functions like 'update'.
Do you switch users on your Mac? I think you should check the permissions (ls -la) of the .hg/attic folder on your local repo, and see if it's owned by a user other than yourself. If it is, you should probably chown it, or if you switch users a lot, change the group permissions to write and set the gid bit so that whatever user you're logged in as, you have access to the attic folder.
Alternatively, if you don't have read access to the shared .hg/attic folder, that may cause a problem too if Mercurial assumes it can traverse all folders in the .hg location. Usually with a shared repo there wouldn't be an attic folder (because it wouldn't be used as a working copy) but maybe in this case the attic folder has been created by another user, and the group it is assigned doesn't even allow you read access. You should try fixing that if so - as I say, hgattic doesn't actually affect the clone or pull functions of Mercurial, but it could be that Mercurial itself is assuming it can read all folders inside .hg.
There is no .hg\attic folder in the remote repository.
Our repositories are so large, that it is infeasible to clone via HTTP; requests time out. So we expose our repositories via Windows shares. We only give read access to the shares so no one inadvertently tries to push to the share because Mercurial can't safely lock a repository using Windows shares. Plus, pulling from the share is much faster than via HTTP. Thus, we pull from a share, and push via HTTP.
Also, our remote repositories don't have working copies.
I'm most curious why Source Tree is trying to write to the remote repository during a pull. Or is it trying to read the .hg\attic file and failing because it doesn't exist? That would beg the question why it's trying to access the attic against a remote repository. I thought the attic was purely a local repository artifact.
It's not SourceTree, it's Mercurial. hgattic does not explicitly alter the behaviour of 'pull' either, so I don't know why this is happening. It certainly doesn't happen with traditional remotes - I have plenty of read-only Mercurial remotes and have never had an issue with attic. I can only assume that Mercurial behaves differently when it's operating on what it perceives to be a local folder, and tries to ensure parity between the 2 folder structures rather than pulling changesets in the more traditional fashion. I know both Git and Mercurial take short-cuts when operating on local folders so perhaps this explains it - your SMB share probably looks local to Mercurial. Yours is not a typical setup because no-one else has reported this before in the 6 months since hgattic has been enabled, and we have a lot of Mercurial users.
There are a lot of other options for hosting repositories other than what you're doing, that wouldn't have the locking issue. If you're having size issues with HTTP, SSH is a great option. That's what I use for all my repositories, it doesn't have the timeout problems that HTTP often has. SSH hosting is super-easy on a Linux/Mac server but there are a number of Windows SSH servers available, including free & open source ones.
But, if you want to sidestep this rather than solving the underlying issue for now, here's a build which allows you to disable the hgattic extension for now: http://downloads.sourcetreeapp.com/SourceTree_test.zip
Thanks much Steve, your help here is much appreciated. Another weird issue I've noticed is that after pushing to the remote repository, the UI will still show that 1 commit needs to be pushed, even though it was already completed:
Eventually it usually goes away, but wanted to mention it so you knew or could maybe look into why this happens.
Thanks again for everything!
Why is it needing to write to the .hg/attic folder when pulling from a remote location? It should not be aborting an "hg pull -u" because I don't have write access to a repository that is read only. We push remotely to an alternative repository where we have write access.
A vulnerability has been published today in regards to Sourcetree for Windows. The goal of this article is to give you a summary of information we have gathered from Atlassian Community as a st...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events