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.
