Committing in TortoiseSVN - When is a good time/What is a good way?



  • Hi,

    I work in an organization where I am the sole developer. I have been using TortoiseSVN for source control. Since I have been using it on my own (i.e. not with a development team), there are many aspects of its functioning I am unclear about. 

    For example, as of now, I commit to the repository very regularly (once every 20 mins), and this is very helpful when I need to undo some stupid mistake I've made, or when I need to steer development in a different direction, etc. However, I realize that in an actual production shop, every developer would check out and commit their code only when their portion of the code works, and is ready for integration with other code (right?). Would it make sense to only commit to the repository when a unit of development is complete? When the code was executable and would compile without errors, but not complete. Or would it make sense to commit to another development branch/tag, and just merge with the trunk whenever I complete a major section?

    Thanks in advance for the help, and sorry if this is a dumb question.

    Donniel 



  • svn can't merge worth a damn (their rationale is that cvs can't merge worth a damn, so cvs users would be confused by merging that actually works, so svn shouldn't implement it), so any plan built around svn should minimise the number of merges, to limit the amount of code lost or mangled by botched merges. If you want a branch-heavy development approach, pick a better tool.



  • To actually answer your question, instead of ranting against percieved or actual poor merging in SVN:

    Consider committing your code as soon as you have:

    • added a new component ...
    • fixed an issue ...
    • refactored existing code ...
    • removed dead code ...

    ... and it actually works.  The idea is to have a nice discrete history of changes along with comments.  Nothing is worse than finding out a bug wasn't fixed properly and seeing a comment that reads "fixed bugs 45, 67, 24, 25, 35, and 46."  Then again, you don't really care about "half-way to fixing one function related to bug number 36" do you?

    You reall just have to get a feel of what amount is worth checking in and what's not. 



  • Hmm....makes sense. Thanks, djork. I think I'll use your advice. asuffield,  what other versioning tools would you recommend? I primarily develop in PHP.

    Regards,

    Donniel 



  • The language you use is irrelevant. The development model is all that matters.

    The main one of the fully-functional revision control systems nowadays is git.

     

    And incidentally, here's some relevant commentary on why svn is so braindamaged:

    @Linus Torvalds said:

    For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN  users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was ‘CVS done right’, or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.

    (For extra amusement, watch how badly it breaks when you try to merge changes on a renamed file - it's really quite hilarious if you know how much of a fuss they made about "supporting renames" a few years ago)



  • @asuffield said:

    The language you use is irrelevant. The development model is all that matters.

    The main one of the fully-functional revision control systems nowadays is git.

     

    And incidentally, here's some relevant commentary on why svn is so braindamaged:

    @Linus Torvalds said:

    For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN  users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was ‘CVS done right’, or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.

    (For extra amusement, watch how badly it breaks when you try to merge changes on a renamed file - it's really quite hilarious if you know how much of a fuss they made about "supporting renames" a few years ago)

    As usual, you have no clue what you're talking about. When was your own personal last review of the functionality of SVN done? And what decade was the quote from Torvalds made?

    Oh, that's right. You know nothing about *anything* current, do you? You just spend all your time bashing MS about things that have nothing to do with them, leaving yourself no time to keep up with technology.

    Donniel: Listen to djork. While I don't usually agree with him/her, in this case the advice is sound.



  • @asuffield said:

    And incidentally, here's some relevant commentary on why svn is so braindamaged:

    @Linus Torvalds said:

    For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN  users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was ‘CVS done right’, or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.

     

    Ok good. Every sentence in that quote can be replaced with "cvs sucks". It contains no information; merely void complaints, and I find its quotability dubious.

    So why does it suck? teh infos plz thx.



  • @dhromed said:

    So why does it suck?

    CVS sucks because it was created to be a mechanism for storing a single sequence of diffs to a bunch of files, onto which branching was very crudely grafted with no real thought, by people who were not very good software engineers (in fact, it's researcher code that crawled out of the lab and ran away).

    Were you expecting some complex story? It's just regular suckage.



  • @asuffield said:



    Were you expecting some complex story? It's just regular suckage.



    Well, that still only looks like half the story; you've just moved the "it just sucks" to a different place.

    And I don't agree that a concept like "regular suckage" exists, as if a similar catch-all anti-suck solution existed -- save weeding out mindstates of fearful dumbness and unwilingness to learn.



  • Thanks Ken.

    assuffied, I'll check out git.

    Donniel 



  •  @dhromed said:

    Ok good. Every sentence in that quote can be replaced with "cvs sucks". It contains no information; merely void complaints, and I find its quotability dubious.

    So why does it suck? teh infos plz thx.

    We depent on CVS over here, and it gets the job done. However, it lacks some features that I see in SVN. Mainly I miss the feature where you can request the history of a directory. "Give me all commit logs from directory X" Also SVN keeps a single version number, which is easy to use as 'debug' version number. No need to label each single test release you do.

    (We don't do branches here, as that simply does not seem to work)

    In all cases, it's free, so I don't complain. 



  • It might be that I'm just tired of silent commits (yeah, I know they can be turned off using hooks), but here's my latest policy:

    Commit if the change is worth writing a reasonable commit log/message. 

    "Fixed bug [bug whose fix was a single ! placement]" is fine, but I usually wait a bit before committing if I'm reviewing/debugging code.

    I also commit after working on A, before moving on to B. (A and B here are different and unrelated modules of a single application, or of different applications.)

     

    You have an opportunity here, that of choosing what you want to see in the repository log. Are you happy with 20 commits with barely ten lines of change in each? With 30 commits that barely amount to a minor version change? If so, then by all means, commit as if it were a "save" function.

     

    My commits look like:

    * Added <something> module

    * Added a helper "getPreferences()" function, and modified X, Y, Z and W to use it instead of <old hacky way>.

    * Removed redundant code from <old module>, moved other functions to appropriate places. [Deleted oldmodule.src, updated x.src y.src z.src] 

    * Fixed bugs <not really important>, <small glitch>, <rare bug>

     

    Well, they really don't, but you get the idea...



  • The same rules apply for both code commenting and commit commenting.



  • @dhromed said:

    The same rules apply for both code commenting and commit commenting.
    That they are never there when you need them?

    Or that some people think they are so good that they don't need them?

    Or that they state the obvious? 



  • Controversy aside, I use and like Subversion.

     The answer to your question is really up to you. If you are the only developer for all-time, then do what suits your needs in the long run. If other people will develop on top of your base, try to think about what would be useful for them when they look back deep into the history.

    Others have provided good guidelines here. Just think about how you'll use the repository. If you always check in code that is working (i.e. passes all unit tests), then you can easily rollback a change in a single command -- I find that to be very useful. When you look at the history of a particular file, you want the history to tell a story. Usually, the beginning of development is quite hectic as lots of stuff is created and added, but overtime it stabilizes and you should be able to make atomic commits that have a very particular reason for being.



  • @Daid said:

    @dhromed said:

    The same rules apply for both code commenting and commit commenting.
    That they are never there when you need them?

    Or that some people think they are so good that they don't need them?

    Or that they state the obvious? 

    Yes. 



  • Very useful advice! Thanks!

    In fact, I had just started doing that, and found that it helps a lot. Earlier, reverting back to an old version was a bit of a dice-roll, because I wasn't sure what was working, what wasn't in that revision. Now, I make sure that all relevant, important changes are mentioned in the commit. If they aren't significant, I hold back the commit for a bit. 

    Donniel



  • Again, good advice. Thanks!

    Donniel 



  • Of course, before you rollback you do a quick diff between the files, right? Like a SELECT before a DELETE.



  • donniel, don't think svn is a poor tool. We use it here in our shop, and although a dozen programmers isn't much compared to some people, svn works just fine. Its widely used amoung open source projects also.  It does take a little management compared to some tools, but all in all its good source control. I agree with others that you should only commit when you've made decent changes.  You also might want to branch off your current development and make a trunk for what holds your "build ready code"  That way you can test in the branch and after everything works, you can merge to the trunk.



  • @pitchingchris said:

    donniel, don't think svn is a poor tool. We use it here in our shop, and although a dozen programmers isn't much compared to some people, svn works just fine. Its widely used amoung open source projects also.  It does take a little management compared to some tools, but all in all its good source control.
     

    This is a variation on the theme of the Blub effect. 



  • Depends on whether I know (remember) what changes I performed in the previous commit - I've rarely had to rollback to any but a version that I have worked on within the last few hours.

    @pitchingchris: Yes, I've found TortoiseSVN to be extremely useful so far. There are times, however, that I use it incorrectly, and then everything stinks to the high heavens! This is occurring far less often now. 

    @asuffield: Sorry, what?!

    Donniel 


  • ♿ (Parody)

    @asuffield said:

    @pitchingchris said:

    donniel, don't think svn is a poor tool. We use it here in our shop, and although a dozen programmers isn't much compared to some people, svn works just fine. Its widely used amoung open source projects also.  It does take a little management compared to some tools, but all in all its good source control.
     

    This is a variation on the theme of the Blub effect. 

     

    Reading your posts reminds me of something that my wife gets mad at me about quite a bit.  You've obviously got a lot of strongly held opinions, and they're probably the result of a lot of work and/or thinking about the topic at hand.  But the short, brusk replies come across as kneejerk responses.  I've never used git, though I've heard a lot of griping about svn.  Most of it boils down to similar to what you've said.  Not a lot of substance.

     Can you give a better, fuller description of how git is better than svn?  It obviously works for Linus, but then most of us probably don't work on projects that look like the Linux kernel.  I've scanned some of the git stuff on-line, but I've never taken enough time to get to know it or really try it out.  Frankly, I don't really see the need, since I don't appear to have [knowingly] run into its shortcomings.

     Not that anyone can stop you from proclaiming the blub effect, but it just makes you look like an anti-social asshole (which maybe you are and maybe you aren't--I know that I often do that when I don't mean to).



  • @boomzilla said:

    You've obviously got a lot of strongly held opinions, and they're probably the result of a lot of work and/or thinking about the topic at hand.
     

    You seem confused about the notions of "opinion" and "research". Research is not an activity that generates opinions. Rather, an opinion is approximately a statement that is not backed by research; they're roughly opposites.

    @boomzilla said:

    But the short, brusk replies come across as kneejerk responses.

    The reader is either sufficiently capable and interested to figure it out when given a hint (so I should give them one), or they aren't interested (so I won't waste their time with an explanation), or they're too stupid, prejudiced, or uneducated to figure it out (in which case I don't really care what they think).

    @boomzilla said:

    Can you give a better, fuller description of how git is better than svn?

    Yes. Can I be bothered to write an essay just to post on some web forum about it? No. I have no stake in any of these tools; I have no reason to try to convince anybody. People who fit the scenarios I have indicated would almost certainly benefit from investigating better tools, but I feel no obligation to do more than indicate to them that such investigation is merited.

    @boomzilla said:

    It obviously works for Linus, but then most of us probably don't work on projects that look like the Linux kernel.

    Quite possibly true. If all you want to do is store a single line of history, without any real branching or distributed operation, then it doesn't really matter what you use. A filesystem with a nightly (hourly, whatever) backup and a changelog would suffice, as would any of the widely available revision control systems.

    If you want to do a significant amount of branching and merging, you should be looking for a better tool; there's four or five of them around, and git's the most polished of them today. (Readers who have arrived via Google six months from now: this may or may not still be true)

    @boomzilla said:

    Not that anyone can stop you from proclaiming the blub effect, but it just makes you look like an anti-social asshole

    That's funny, I have a similar opinion of people whose response to criticism of a tool is to say "That's wrong because it works for me", except that I use more adjectives.



  • I noticed that it wasn't mentioned but you can also do hybrid. Which depending on the way you want to work might suck or not suck.

    But basically you can have your main stable branches and head/trunk in SVN, and use git developer side. This will make it easier to have seperate local copies so you can have fresh copies of trunk while working on several bugs/features. And if bugs depend on eachother you can use git to merge them easily (or so i've heard, haven't really played with that yet). even if one of those bugs was currently in the hands of another developer.

    Then when you happy with the state of you changes you can commit them back to SVN. 

    This setup gives you the versatility of git with the industry expectation of the svn/cvs model. So developers that don't like new things can still use just plain svn. 


  • ♿ (Parody)

    @asuffield said:

    @boomzilla said:

    You've obviously got a lot of strongly held opinions, and they're probably the result of a lot of work and/or thinking about the topic at hand.
     

    You seem confused about the notions of "opinion" and "research". Research is not an activity that generates opinions. Rather, an opinion is approximately a statement that is not backed by research; they're roughly opposites.

    OK, poorly phrased.  "You've come to some decisions after significant thought/research/work."  That was what I was trying to convey. 

    @asuffield said:

    @boomzilla said:
    But the short, brusk replies come across as kneejerk responses.
    The reader is either sufficiently capable and interested to figure it out when given a hint (so I should give them one), or they aren't interested (so I won't waste their time with an explanation), or they're too stupid, prejudiced, or uneducated to figure it out (in which case I don't really care what they think).

    Well, you usually come around and give more than a hint after several replies, etc.  There's a pretty wide range of experience around here, both in terms of breadth and depth of subject matter. @asuffield said:

    @boomzilla said:
    Can you give a better, fuller description of how git is better than svn?

    Yes. Can I be bothered to write an essay just to post on some web forum about it? No. I have no stake in any of these tools; I have no reason to try to convince anybody. People who fit the scenarios I have indicated would almost certainly benefit from investigating better tools, but I feel no obligation to do more than indicate to them that such investigation is merited.

    But you do feel enough to write posts that come off as insulting people who find a certain tool [not favored by you] to be sufficient for their purposes.  Maybe you don't mean to be, but that's certainly how it seems to come across.  Of course, you're not obligated, but when you start throwing out these little hints, why would you be surprised that others with less knowledge would ask you about them?  Again, not that you have to respond with an essay.  Maybe you really want to be rude when people ask follow-up questions.@asuffield said:
    @boomzilla said:
    It obviously works for Linus, but then most of us probably don't work on projects that look like the Linux kernel.

    Quite possibly true. If all you want to do is store a single line of history, without any real branching or distributed operation, then it doesn't really matter what you use. A filesystem with a nightly (hourly, whatever) backup and a changelog would suffice, as would any of the widely available revision control systems.

    If you want to do a significant amount of branching and merging, you should be looking for a better tool; there's four or five of them around, and git's the most polished of them today. (Readers who have arrived via Google six months from now: this may or may not still be true)

    I definitely get the distributed operation part.  That's obviously a big part of why git is interesting.  And I've often heard about git being better at merging, but I don't think anyone has ever said why.  After a little googling, I found this page:

    Git - SVN Crash Course 

    The advantage of git over svn in merging seems to be that you don't have to know when the branch was created, and also that you apparently retain the history of both branches better.  I'm guessing that this means you retain all of the commit logs, plus the history diagrams.  Maybe there are other issues, but that's those are the main things I got from git's crash course for svn users.

    @asuffield said:

    @boomzilla said:
    Not that anyone can stop you from proclaiming the blub effect, but it just makes you look like an anti-social asshole
    That's funny, I have a similar opinion of people whose response to criticism of a tool is to say "That's wrong because it works for me", except that I use more adjectives.
    Well, I tend to think that those people are just ignorant, or [depending on the context] are simply shutting down the conversation after they feel like they've been insulted because they've taken what was meant to be a criticism of their tools as a criticism of their person (and not always unreasonably).



  • Thanks everyone for the great advice!

    Regarding the Git vs. SVN debate, personally, I prefer to switch to a new tool only if the existing tool is not up to the mark. Of course, if somebody suggests that another tool does the job better, I will give it a whirl, research it, etc. However, I usually wait till I've received some concrete reasons as to why this tool is better before going through the effort of finding out more about it.

    To give an example, if somebody tells me that Linux is great, I won't immediately go out and research it, try it out, etc. If they said however, that Linux was great for developers, because it offered a better development environment due to feature A and B, I would invest time in trying to figure it out.

    Git seems to be a great tool, but doesn't seem to have an idiot-proof GUI like TortoiseSVN for SVN (I could be wrong, this is based on a few minutes of Googling). I wouldnt' have dreamed of using SVN were it not for the wonderfully intuitive and easy-to-use interface. Again, this is about personal preferences, I'm not saying one is better than the other. I haven't had a problem tagging/branching under SVN yet, but this might be a case of waiting to get burnt before learning the lesson :)

    Cheers,

    Donniel 


Log in to reply