1

our company wants to switch from svn to git/hg.

Our current environment is:

  • Windows-Dev-Machines
  • Remote Linux Server (via 1 Gbit LAN)
  • Samba Share on Server, mapped in Windows

We don't want to work locally, because of backups (serverside) and running VMs on localhost etc (PHP-Webserver).

So I can clone from Server via SSH into the mapped Drive (say Z:\), which is in fact the same Linux machine.

We've got a Repo with around 20k Files, so the git status takes like forever (because it's remote).

Can we tell git/hg (or a client) to also SSH into our Z:\ ?

We also have the idea of running everything on C:\ and syncing it via ssh to the document-root of the server, but it doesn't feel right...

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
SebaGnich
  • 49
  • 6
  • 2
    why are you trying to re-invent a wheel? Distributed version system as git works well when you have one master and users clone that source and once they are done with some feature or bugfix, they commit and push. It is not so hard. Having all devs working together with a single master would cause a lot of mess. – Jakuje Jan 02 '17 at 17:18
  • Hi, please look at my comment below. We have one master, and everyone's cloning from it. But also everyone has his working directory on the same dev-server (with different locations and document-roots of course). – SebaGnich Jan 03 '17 at 07:47

2 Answers2

2

"We also have the idea of running everything on C:\ and syncing it via ssh to the document-root of the server"

Working with a distributed VCS (Git/Hg) means working locally: those tools have been design to minimize latency: no network connection of any kind (except for clone/pull/push)

Putting your repo on Z: is acceptable, but working (status, commit, ...) directly on a network drive is not.
Simply clone your repo on Z: to C:, and work locally. When you are done, push back to the Z: repo. Especially since Git 2.3+, which allows you to push to a non-bare repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • We work remotely, because we want to see our changes directly (Web-Dev, so "save and look", instead of pushing something somewhere), and everyone else in the network can see my development state (like devname.www.google.com). The dev-server has the same config (PHP, Ubuntu, MySQL...) like the live systems, so we don't want to work on localhost with wamp or anything like that. – SebaGnich Jan 03 '17 at 07:43
  • @SebaGnich no problem: work locally and then push: that is how git is working in order for everyone to see what is published remotely. – VonC Jan 03 '17 at 07:50
  • @SebaGnich "we don't want to work on localhost with wamp or anything like that": that owuld be better (to be able to reproduce an execution environment locally), but if you can't, work locally (still) and push to see the effect on your change in the remote environment. – VonC Jan 03 '17 at 07:52
  • Localhost would have some other disadvantages (everyone has to have their own database maintained and so on), and we have some people here that just want to do frontend and I don't want them to learn too much new stuff. Everything is working fine at the moment, I just wanted to introduce branches. Looks like Mercurial has good performance in terms of `hg status` on our repo. – SebaGnich Jan 03 '17 at 08:15
0

If you don't fear the command line, you can use Mercurial or git via SSH on the server. This is much faster, since the tools on the server have the advantage to use there the local file system, instead of squeezing everything through the much slower SMB protocol.

When you insist of running the client on the windows side, you usually can configure your client to use a different hg/git executable, which you then replace by a script which forwards all commands via ssh to the server. But such solutions tend to be very brittle, and I would advice very much against it.

Rudi
  • 19,366
  • 3
  • 55
  • 77