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.
