Version control for non-coders



  • I'll start off by letting you all know that I have very little coding experience.  That which I do have is mostly vb.net that I was forced to take at Uni. 

     

    My current problem is this:

    I am a network analyst where I work.  Mainly this means that I'm responsible for hardware and to make sure that the OS is correctly loaded on PCs.  The software analysts are responsible for dealing with the various programs we have.  Unfortunately, they are pretty worthless, and are a glorified help desk, because all they do is send the issues to us or the vendors.  To make life easier, we've started packaging and scripting the software they are responsible for.  We are looking for a way to control the scripts as we have different versions for the same packages.  So we need a version control that is independent of any development tools as we don't use one.  Does anyone know of any free product that would work like this?  And it has to be free, because they refuse to pay for anything for us to make this simpler.



  • A suitably fluffy question deserves a suitably fluffy reply


    • Subversion
    • git
    • Visual Source safe (included for hilarity - this isn't a serious one)
    • Google for [version control] that doesn't mention any of the above for possible suitable alternatives


  • It sounds like any of them would work.  You'll have to maintain the repository and do a little training with your users on how to add files and commit.  Maintenance is little more than creating it in the first place. 

    SVN and CVS are the most popular, but one moderator on here prefers git because it can do distributed repositories.  I've only used SVN, so that's what I'll recommend.  I recommend TortoiseSVN as the client tool for your users' Windows machines.  

    As a side question, I always commit with a message.  Do any of you find the commit messages useful?  I haven't found much use for them, but my OCD nature requires I do it anyway, because "what if I need them at some point?"


  • Discourse touched me in a no-no place

    @belgariontheking said:

    As a side question, I always commit with a message.  Do any of you find the commit messages useful?  I haven't found much use for them, but my OCD nature requires I do it anyway, because "what if I need them at some point?"
    Good issue tracking software can cross-reference your repository with your issues. For example, I've hacked Flyspray to look for FS#nnnn notations in the commit messages. My time tracking software also looks for job numbers. 

     

    As a human, I've never actually read the things.



  • Well, I don't actually need to cross reference between my repository and my issue tracking software...because we don't have issue tracking software.  We're not actually developers, we're just hardware folks trying to make our lives easier by scripting, and our scripting easier by having a repository so the engineers can't mess up our scripts or put the wrong one out for use.

     

    Also, thanks to  Btk and PJH for suggesting Subversion.  I got it installed and working in about 20 minutes on a test server.  The guy that does most of the scripting loves it so much that he put it on the server we "acquired" from the engineers to do our deployments.  Really appreciate the help.  Cheers!



  • @belgariontheking said:

    Do any of you find the commit messages useful? 
    Yup. As a summary of what other people changed in that revision, and what's happened between 'then' and now. svn log -r4538:4595 is a lot quicker than diffing and trying to figure it out. Assuming of course that the cow-orkers in question bother putting anything in there.



  • @PJH said:

    Assuming of course that the cow-orkers in question bother putting anything in there.

    While we're off topic, what does everyone think about longer vs shorter commit messages?  Short description of just the change, or a problem (or feature) description too?



  • @arty said:

    While we're off topic, what does everyone think about longer vs shorter commit messages?
    Whichever suits the situation. Usually I just list bullet points of changes, BR/FRs affected/closed/etc...



  • @arty said:

    @PJH said:

    Assuming of course that the cow-orkers in question bother putting anything in there.

    While we're off topic, what does everyone think about longer vs shorter commit messages?  Short description of just the change, or a problem (or feature) description too?

    Personally, I just prefer using a bug/task ID.



  • @arty said:

    what does everyone think about longer vs shorter commit messages?
    What's "short" and what's "long" to you?  to me "fixed that thing" is short and more useless than no message.  I put "fixed <problem>\nAdded <feature> ...." which may be long to you.



  • @belgariontheking said:

    What's "short" and what's "long" to you?  to me "fixed that thing" is short and more useless than no message.  I put "fixed <problem>\nAdded <feature> ...." which may be long to you.
     

    Rule of thumb: if you need three full lines in a 200px wide comment box, you've messed up and need to start over.



  • @dhromed said:

    @belgariontheking said:

    What's "short" and what's "long" to you?  to me "fixed that thing" is short and more useless than no message.  I put "fixed <problem>\nAdded <feature> ...." which may be long to you.
     

    Rule of thumb: if you need three full lines in a 200px wide comment box, you've messed up and need to start over.

    If you're using Subversion, for example, your comment box is Notepad.



  • @Spectre said:

    @dhromed said:
    Rule of thumb: if you need three full lines in a 200px wide comment box, you've messed up and need to start over.
    If you're using Subversion, for example, your comment box is Notepad.
    Um, no it's not. On two boxes I use regularly:

    [@hpc ~]# ssh 192.168.4.190 grep editor-cmd /etc/subversion/config

    editor-cmd = editor (vi, emacs, notepad, etc.)

    editor-cmd = /usr/bin/kwrite

    [@hpc ~]# grep editor-cmd /etc/subversion/config

    editor-cmd = editor (vi, emacs, notepad, etc.)

    editor-cmd = /bin/vi



  • @PJH said:

    @belgariontheking said:
    Do any of you find the commit messages useful? 
    Yup. As a summary of what other people changed in that revision, and what's happened between 'then' and now. svn log -r4538:4595 is a lot quicker than diffing and trying to figure it out. Assuming of course that the cow-orkers in question bother putting anything in there.

    I revert any commit where the message is significantly different from the actual change committed.  My cow-workers hate me, but my change history makes sense.  I also demand that commits be scrubbed on non-changes.  Any tabs-to-space conversions that weren't intentional or some GUI designer changing layout just pollutes the change history and sometimes makes merging a nightmare.



  • @PJH said:

    @Spectre said:
    @dhromed said:
    Rule of thumb: if you need three full lines in a 200px wide comment box, you've messed up and need to start over.
    If you're using Subversion, for example, your comment box is Notepad.
    Um, no it's not. On two boxes I use regularly:

    [@hpc ~]# ssh 192.168.4.190 grep editor-cmd /etc/subversion/config

    editor-cmd = editor (vi, emacs, notepad, etc.)

    editor-cmd = /usr/bin/kwrite

    [@hpc ~]# grep editor-cmd /etc/subversion/config

    editor-cmd = editor (vi, emacs, notepad, etc.)

    editor-cmd = /bin/vi

    Real men use heredocs directly from the command line.



  • @Jaime said:

    I revert any commit where the message is significantly different from the actual change committed.  My cow-workers hate me, but my change history makes sense.  I also demand that commits be scrubbed on non-changes.  Any tabs-to-space conversions that weren't intentional or some GUI designer changing layout just pollutes the change history and sometimes makes merging a nightmare.
    I don't have a whole lot of experience trying to merge branches, as I am the only developer on most of my projects and I just kind of keep it trunked, so this seems silly to me.  

    But then again, I don't work for a large travel website.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.