6

I use Ubuntu 16.04 and Mercurial 3.7.3. Our repository is accessible only as an SMB share. I cloned the share to a folder in my home folder (I simplified the names a bit):

> hg clone "/run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo" Repo

My problem is that I can do anything (pull, commit etc.) but push:

> hg push -v
pushing to /run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo
searching for changes
2 changesets found
uncompressed size of bundle content:
     876 (changelog)
     724 (manifests)
     586  a.txt
    2869  b.txt
   34900  c.rpm
   37325  d.rpm
abort: Operation not supported: '/run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo/.hg/store/journal'

If I use sudo:

> sudo hg push -v
[sudo] password for kol: 
pushing to /run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo
abort: repository /run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo not found!

Thanks for your help in advance!

UPDATE

I tried the same in Windows 7, and hg push worked.

UPDATE 2

The SMB share is on a Windows machine.

The output of hg push on Ubuntu with the --debug option (the commit I tried to push is different than the above):

> hg push -v --debug
pushing to /run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo
query 1; heads
searching for changes
all remote heads known locally
listing keys for "phases"
checking for updated bookmarks
listing keys for "bookmarks"
listing keys for "bookmarks"
1 changesets found
list of changesets:
9ce3f6fbf7217a7eea79cf21ccbb2d7fc851cbd3
bundle2-output-bundle: "HG20", 4 parts total
bundle2-output-part: "replycaps" 155 bytes payload
bundle2-output-part: "check:heads" streamed payload
bundle2-output-part: "changegroup" (params: 1 mandatory) streamed payload
bundle2-output-part: "pushkey" (params: 4 mandatory) empty payload
abort: Operation not supported: '/run/user/1000/gvfs/smb-share:server=xyz.com,share=abc$/Repo/.hg/store/journal'
kol
  • 27,881
  • 12
  • 83
  • 120
  • On which system (Linux / Windows etc.) does the SMB server run? – Manuel Jacob Jun 02 '16 at 12:30
  • Also, can you try if adding `--debug` as an argument gives useful information? Does `dmesg` show anything interesting while you try the push? Running `dmesg | tail -f` could be helpful to see what's happening. – Manuel Jacob Jun 02 '16 at 12:43
  • @ManuelJacob Please see my 2nd update. – kol Jun 04 '16 at 17:39
  • @ManuelJacob There is nothing interesting in `dmesg` output. – kol Jun 04 '16 at 17:41
  • @kol what about mounting samba share to ypur local file system and working with it afterwards? Then Mercurial will deal with it like with standard file system. – Jehy Jun 06 '16 at 11:19
  • 1
    @kol The mountpoint is strange... What if you mount your smb fileshare via an other tool, as `cifs-utils`? – Vincent Jun 06 '16 at 12:10
  • 1
    I had the same problem and followed @Vincent 's advice. I can push with cifs where I could not with gvsd. I had to add a line to /etc/fstab in order to cifs mount as non-root with `user` option and also to specify my `username` for the samba share. (there are security issues, I am content to enter my password every time I mount, alternatives include a credentials file, see mount.cifs doc for details) – Chip Grandits Mar 21 '17 at 15:48

2 Answers2

1

For some reason, this seems to not work with GVFS-mounted directories. CIFS works, though. So, to push to the remote repository, mount it via CIFS.

sudo mount -t cifs -o user=your_remote_username,domain=your_remote_domain,uid=$(id -u),gid=$(id -g) "//remote.server.com/path/to/remote/directory" /media/your_user/smb-mount

Make sure to set your remote (SMB) username and domain. Also, in case the server sends ownership information for the files, it might be required to add the forceuid,forcegid options. For a full description of the command, see Mount cifs Network Drive: write permissions and chown.

Chris
  • 6,914
  • 5
  • 54
  • 80
0

Please please please do not use network filesystems for any version control system. Network filesystems violate some of the consistency guarantees that most version control systems depend on - what you're seeing with the journal file is almost certainly a side effect of that.

Instead, can you run an http hg server on the same machine? That'll significantly reduce your risk of data loss.

durin42
  • 1,447
  • 8
  • 10