distributed version control systems let each developer have a full repository
locally on their machine, they then can send updates to other people who have a
repository (or a pull request which asks the other person to pull from the
developers repository to the other persons repository)
Most projects have one repository that they designate as being the 'main'
repository for the project, and developers push updates to it (or send pull
requests to the people who own that repository)
The communication between developers is typically via e-mail and the repository
updates are sent via the git-daemon and the git network protocol.
This sort of thing is very different from the model where there is one
repository on a shared disk somewhere and everyone accesses that shared disk to
do their work or apply updates via NFS/CIFS protocols.
Does this clarify the difference?
David Lang
On Thu, 17 Jan 2013, Lang, David wrote:
Hi David,
Ok, now I'm really lost! This is definitely due to my newbie git status but
I'll ask anyway. I'm confused by your statement "... if you try to have one
filesystem, with multiple people running git on their machines against that
shared filesystem, I would expect you to have all sorts of problems."
Isn't that the whole point of git, or any versioning system? I thought the
idea was that each developer installed git locally on their machines and (as
needed) committed their changes to the master repository which resides
externally to any of the local machines, such as on a network server (and
which I'm assuming has git installed locally as well).
What am I missing?
The 'other' David Lang ;-)
-----Original Message-----
From: David Lang [mailto:da...@lang.hm]
Sent: Wednesday, January 16, 2013 6:01 PM
To: Stephen Smith
Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David
Subject: Re: Question re. git remote repository
On Wed, 16 Jan 2013, Stephen Smith wrote:
Ideally we'd prefer to simply create our remote repository on a
drive of one of our local network servers. Is this possible?
Yes, this is possible, but it's not advised to keep such a
"reference" repository on an exported networked drive for a number
of reasons (both performance and bug-free operation).
I agree that performance is not ideal (although if you are on a fast
LAN, it probably would not matter much), but I do not recall any
specific bugs in that area. Can you elaborate?
This one [1] for instance. I also recall seing people having other
"mystical" problems with setups like this so I somehow developed an
idea than having a repository on a networked drive is asking for troubles.
Of course, if there are happy users of such setups, I would be glad
to hear as my precautions might well be unfounded for the recent
versions of Git.
1. http://code.google.com/p/msysgit/issues/detail?id=130
A group I was with used a master repository on a windows share for quite some
time without a database corruption being seen. --
I think the risk is that if you have multiple people doing actions on the
shared filesystem you can run into trouble.
As long as only one copy of git is ever running against the repository, I don't
see any reason for there to be a problem.
But if you try to have one filesystem, with multiple people running git on
their machines against that shared filesystem, I would expect you to have all
sorts of problems.
David Lang
This e-mail may contain confidential and/or privileged information for the sole
use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was
originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete
all copies.
Opinions, conclusions or other information contained in this e-mail may not be
that of the organization.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
