Is there a way to allow SourceTree to pull from one location, and push to another?

[Ryan Tait]

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?

[stevestreeting · Accepted solution]

Hmm, no the hgattic extension is always enabled. I don't understand why that particularly would cause you an issue though, since the attic is not pushed or pulled, it's local. What were you doing what you got that error?

[Ryan Tait]

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?

[stevestreeting]

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.

[stevestreeting]

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.

[Aaron Jensen]

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.

[stevestreeting]

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

[Jonathan Simcoe]

Thanks Steve, this should work in the meantime until we get something figured out internally. Will this build auto-update or will we be forced to use just this version with the option enabled to remove hgattic?

Thanks again!

[stevestreeting]

I mulled this over and I've committed this option to the official codebase so it will be preserved in future updates, the big warning sticker on the extensions section will hopefully deal with any unwise use!

[Jonathan Simcoe]

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:

http://cl.ly/051I1d1z0Q1j363P0W37

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!

[stevestreeting]

Hmm, that's odd because the standard behaviour is to reset the push count to 0 after pushing since it's safe to assume there are no more outgoing changesets. I'll investigate.

[Jonathan Simcoe]

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.