Git performs pretty poorly (relative to ssh) with a bare repo on a network share as well, as the pack-send support is optimized for local disk implementation and they assume you'll use ssh and a local bare repo on the remote ssh session. Basically when you clone / update to a network share all the really small disk accesses that git does (quite numerous) take much longer...
In our case this was exacerbated by a 100mb network path rather than gig-ethernet. Also, the OP was specifically asking about following the same work pattern as the existing users workflow which is why I spoke of a gatekeeper and using rdp to the working dir for doing commits and pushes. I would never recommend this workflow, but if the OP insists on trying to be faithful to it, I think rdp is the best approach that will scale. On Nov 2, 2011 12:35 PM, "Richard Turner" <[email protected]> wrote: > Not sure why you were seeing major slowness with GIT unless you had > multiple users pointing at a single repro that was stored on a (possibly > slow) network share? That’s a recipe for disaster with DVCS’. Rather, each > dev should have their own repo(s) locally on their dev machine(s), should > work on their local copy of the source and push changes to the master repo > as and when they’re done with each change or set of changes?**** > > ** ** > > I started out with DVCS’ using GIT and got terribly confused by all the > references to setting up SSH, etc. As a Windows developer, SSH is rarely > used but all the docs at the time said it was necessary (due to GIT’s Linux > heritage).**** > > ** ** > > It turned out that all I needed to do was setup a bare repository on a > network share and have local repo’s on each dev’s machine. Each dev clones > the master repo, and creates their own working branch(es) in which they’re > free to hack away without annoying anyone else. Then, when it’s time, they > merge their changes into a shared/feature branch, run integration tests to > make sure they haven’t broken anything and then push the changes up to the > central repo, whereupon others can “see” their changes.**** > > ** ** > > However, while it’s been much-improved of late, at the time, GIT was still > a little too clunky to use easily - even with > TortoiseGIT<http://code.google.com/p/tortoisegit/>- and so I decided to try > out Mercurial (Hg) via > TortoiseHg <http://tortoisehg.bitbucket.org/>. **** > > ** ** > > We enjoy using Hg so much I’ve moved all our sources for all our projects > to Hg. We use BitBucket <http://bitbucket.org> as our offsite, central > master repo to which everyone pushes all their commits and from which they > pull the latest code. Even our build server just pulls from the BitBucket > master, builds the code, runs the tests, emails the result report and > rotates the staged bits … rinse and repeat. We no longer have any master > repo onsite – we just push everything up to BitBucket. And if BitBucket > dies, we have multiple duplicate copies of the entire repo – one on each > dev’s machine so could re-create our own master repo again if we want or > even push to a new host.**** > > ** ** > > Unlike GitHub which only supports GIT, Atlassian also recently added > support for GIT repo’s so you can pretty much arbitrarily use GIT/Hg and > enjoy the same login, reporting, issue tracking, Wiki, etc.**** > > ** ** > > Works a treat for us J**** > > ** ** > > Since BitBucket is also an Atlassian product/service, it should integrate > nicely into Jira since it comes from the same company.**** > > ** ** > > NB: I have no affiliation with Atlassian or BitBucket – just love their > service J**** > > ** ** > > Richard Turner**** > > E: [email protected] | T: @bitcrazed <http://twitter.com/#!/bitcrazed> | > W: http://www.bitcrazed.com **** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Mario Pareja > *Sent:* Wednesday, November 02, 2011 05:42 > *To:* [email protected] > *Subject:* Re: SCM brainstorming - multiple devs working on the same > source copy on a network share**** > > ** ** > > I too experienced this horrible slowness. This is why I switched to > Dropbox and git combo.**** > > ** ** > > I would be a bit concerned about the checkin process, though. Git's index > is stored on the file system, so staging files that you want to commit will > stage them on all machines. I suspect SVN's checkbox selection before > commit doesn't touch the file system and would give users a bit more > isolation during the commit process. Just something you might want to > check out.**** > > ** ** > > Mario**** > > ** ** > > > On 2011-11-02, at 4:48 AM, Kelly Leahy <[email protected]> wrote:*** > * > > I don't know what other people's experience is with this, but last time I > tried to use git on windows (msysgit) with my git repo on a network drive, > it was HORRIBLY slow, basically to the point of being unusable.**** > > **** > > It could have just been the network infrastructure at my company and/or > the particular way I had things set up, since this was my first time using > git. That said, I think git was designed under the assumption that you > would be using a local filesystem for the location of your working copy and > repo (and would push through ssh or some other mechanism that is also > working with a "local" .git folder).**** > > **** > > What about hosting the "shared" code on a machine that one of the > developers can remote into and do all the git commands there, including > pushing to another remote so they have backups of their git repo? That > seems like it could fit the model of shared source pretty well, and then > when everybody is ready to do a "commit", the "owner" of the source RDPs in > and does the commit.**** > > **** > > Obviously, you lose a lot of the advantages of git this way, but it would > probably allow them to work in a way very similar to how they work now and > get the benefits of a real VCS. BTW, in this case, I doubt it really > matters what the VCS is. The reason I would suggest git is more about > migration to another approach later (it's really pretty easy to change the > location, usage pattern, merge / split, etc. git repos - doing so with SVN > or some other VCSes is probably not as easy - though I don't know for sure). > **** > > **** > > Kelly**** > > On Tue, Nov 1, 2011 at 11:01 PM, Tim Erickson <[email protected]> wrote:*** > * > > Whoah! You have build/deployment engineers? Spoiled rotten, you are! ;-) > **** > > ** ** > > On Tue, Nov 1, 2011 at 10:47 PM, Jeff Schumacher < > [email protected]> wrote:**** > > I think you hit it right there: "Sounds like they want to be more serious > about their system, but just need to be pushed over the hump in a friendly > fashion to do the mental work of learning something like SVN or git." > That's what I think my recommendation is going to be. I know it's probably > the best answer, just as everyone else has pointed it. > > Getting DB schemas into VCS isn't all that hard, we do it all the time at > Russell (and have about 5 different ways of doing it) :D The hardest part > there is deployment. You have to get devs to stop making changes in the > production server.**** > > ** ** > > On Tue, Nov 1, 2011 at 10:31 PM, Tim Erickson <[email protected]> wrote:*** > * > > Honestly, I think what they want (change set <-> bug, revision history and > VC'ed DB schema) without them each learning a VCS, but I don't know if > they're really going to see the benefit of it without learning almost as > much re: version control. IOW, someone else could check their stuff in and > comment it to tie it to a Jira item, but they're going to have to learn > some VCS-related tools (diff viewer, log viewer, etc) to *use* that data > unless they ask someone else to pull a report for them, which I don't > expect will be terribly satisfactory in a workflow scenario.**** > > ** ** > > Sounds like they want to be more serious about their system, but just need > to be pushed over the hump in a friendly fashion to do the mental work of > learning something like SVN or git.**** > > ** ** > > On an immediate practical side I can say they don't really need to know > VCS, but considering what they say they want and how careful it sounds they > are re: their process, I shouldn't think they should either have too much > trouble learning SVN with some friendly coaching nor difficulty integrating > its use into their process. Some reinforcement of the benefits and > reminder that they outweigh the initial effort may be all that is required. > **** > > ** ** > > Or I could be wrong :-)**** > > ** ** > > Getting DB schema into VCS I leave to someone braver than myself. I've > only succeeded to *any* degree via Linq to SQL and hand-rolled sql and > batch scripts.**** > > ** ** > > On Tue, Nov 1, 2011 at 9:50 PM, Jeff Schumacher <[email protected]> > wrote:**** > > Great points Tim. > > So they don't need offline file editing, I asked. They do have a manual > "Hey I'm working on this file" system, and rarely bump into each other. > What they would like is the benefits of tying their commits (they don't > really have 'commits' right now though) to their work items in Jira. Also > to be able to see a history of files, and the next step would be to get > their database schema committed into the VCS.**** > > ** ** > > On Tue, Nov 1, 2011 at 9:45 PM, Tim Erickson <[email protected]> wrote:**** > > What's the problem with the concept of checking out a file and why would > they need to know about it? Checking out a file in svn does not lock that > file (though I think it does support that model if you want to configure it > that way - it is not the default). One person who knows more and or is > more comfortable with VCS in general could manage the check outs / commits > and the others just continue merrily working on their way. > > So SVN or git (or Hg or insert your sexiest DVCS here) would be my initial > suggestion. My concern would be the file system overhead of the VCS - of > which I think SVN and git both have their share. You might want to stick > with command line only and probably git has the edge here as it only has to > maintain control files in one folder at the top level vs a set in every > controlled folder. Thus git wins in terms of ad hoc folder/file > creation/movement/deletion.**** > > ** ** > > The bigger problem of course would be concurrent editing of the same or > related files but it sounds like they've already developed a process to > manage that regardless of VCS "help".**** > > ** ** > > I'd be tempted to say leave well enough alone unless they see value in > tooling to support diffing their backups (aka revisions). Or the ability > to edit offline, which you can do without DVCS btw ;-)**** > > > On Nov 1, 2011, at 8:41 PM, Erick Thompson <[email protected]> > wrote:**** > > I think that git or Hg would be a good fit. The problem with SVN is that > it has the idea of "checking out" a file. It sounds like they haven't > worked that way in the past, so a file based solution seems like a good way > to go. **** > > **** > > If they generally work on different files (i.e., non-overlapping files) > then git becomes very easy. Even if there are conflicts, it isn't usually > too bad. It sounds like the whole branching model is not something that > would benefit them, so a simple master only repo would work. Git gui is > good for simple stuff, and it is a nice clean interface that doesn't get in > the way. Even non-tech folks that I know quickly become comfortable with it. > **** > > **** > > Erick**** > > **** > > > > **** > > On Tue, Nov 1, 2011 at 8:21 PM, Mario Pareja <[email protected]> > wrote:**** > > If it is their first time using source control, starting them with DVCS > might save them the "unlearning" that others are having to do!**** > > ** ** > > ** ** > > On 2011-11-01, at 11:16 PM, Adron Hall <[email protected]> wrote:**** > > Do they have stuff beyond just the code and general web assets? In other > words, are their any others such as graphic artists, documentation people, > or such that want to keep a "backup" of their work? If so, that may be a > consideration too. **** > > ** ** > > If it is all static content, text based, I think whatever would be the > easiest to teach them to use would be the best option. If they're GUI > oriented, Tortoise + Subversion would probably be ok. If they're a bit more > advanced and especially if they do any remote work, I'd push for some > distributed control, i.e. good ole' Git or Mercurial.**** > > ** ** > > Just my 2 cents. Other than that, if these seem like a bit much, I say > just stick multiple copies in Dropbox and call it a day. :)**** > > ** ** > > -Adron**** > > On Tue, Nov 1, 2011 at 8:10 PM, Stevi Deter <[email protected]> wrote: > **** > > I know it's not what all the cool kids are using these days, but I've had > excellent success using SVN in similar situations. > > Heck, I've even managed to get database devs to check their code into SVN. > > -Stevi **** > > > > > On Tuesday, November 1, 2011, Jeff Schumacher <[email protected]> > wrote: > > So imagine there is a team that has an old sckool setup, where there are > multiple developers working on the same copy of source code that exists out > on a network share. Also say that this application could be > ASP.NET<http://asp.net/>, > Classic ASP, or even PHP. The company only has 3 developers, and they > rarely run into either other. One person is responsible for rebuilding the > application, and this practice has been working for this team for years. > They get stuff accomplished, and that is key. They do not run local copies > of the application due to various reasons (this is not the point I'm trying > to argue, as I don't agree with this setup). This team also learned a long > time ago that backups are critical, so they have an automated system on > this network share that detects file changes and makes a archived, > timestamped, copy of the time. It's basically a rudimentary source control > system. > > > > Now, this team knows that they need to get with the times and use a > proper SCM, and they would also like to link their commits with their bug > tracking system, which happens to be Jira. So the question is, what SCM do > you think would work in their current shared source base setup, and why? I > have my opinion on which SCM I think might work, but rather than taint > suggestions, I'll leave my opinion out for the moment. > > > > > > Jeff > > > > -- > > You received this message because you are subscribed to the Google > Groups "Seattle area Alt.Net <http://alt.net/>" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > **** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net <http://alt.net/>" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > > > **** > > ** ** > > -- > *Adron B Hall***** > > *Tech*: http://compositecode.com > *Transit*: http://transitsleuth.com > *Twitter*: http://www.twitter.com/adron**** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net <http://alt.net/>" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > > > > -- **** > > (◣_◢)**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > > > > -- **** > > (◣_◢)**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en.**** > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
