Website Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • August 30, 2015, 11:48:28 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Tortoise SVN and online repositories  (Read 2180 times)

kyrathaba

  • N.A.N.Y. Organizer
  • Honorary Member
  • Joined in 2006
  • **
  • Posts: 3,087
    • View Profile
    • Read more about this member.
    • Donate to Member
Tortoise SVN and online repositories
« on: October 06, 2010, 05:50:29 PM »
I've been using Tortoise SVN for about a month now to backup my work on a C# project.  Love it!  Anyone have any knowledge about how to do revision numbers?  I confess I really don't understand revision numbers.  I've been occasionally updating my "version" as I add considerably more features.  Now I'm at v1.2, but don't have any rational why it's "1.2" and not 0.99 or 1.3.  Any help?

Also, anyone have any experience creating patches with Tortoise SVN?

Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 7,038
    • View Profile
    • Just for mouser.
    • Donate to Member
Re: Tortoise SVN and online repositories
« Reply #1 on: October 06, 2010, 06:07:38 PM »
Revision numbers or software versions?

AFAIK, revision numbers are automatically assigned by each commit to the repository.

As for software "versioning," it's largely up to you how to do it. Quite often I see the format as something similar to major.minor.build.revision.

I personally follow a format something like this:

major.year.month.day[.minor/build/whatever I feel like at the time]

Although I haven't been completely consistent with that system. In one case I've actually done major.build.year.month.day. You can click the little icons in my signature for more examples, if you feel so inclined.

I just like the idea of the date being in the version so you can easily tell at a glance how long it's been since the last update. But it does lack the simplicity of being able to say "Upgrade from 1.2 to 1.3 now!" I'd have to say "Upgrade from 1.2010.10.01 to 1.2010.10.05 now!"

EDIT: Spelling and clarification, etc.

« Last Edit: October 06, 2010, 06:15:33 PM by Deozaan »

kyrathaba

  • N.A.N.Y. Organizer
  • Honorary Member
  • Joined in 2006
  • **
  • Posts: 3,087
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Tortoise SVN and online repositories
« Reply #2 on: October 06, 2010, 07:38:14 PM »
Thanks, Deozaan.

Question: how do you identify what a "major" versus "minor" revision is?

Renegade

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 12,785
  • Tell me something you don't know...
    • View Profile
    • Renegade Minds
    • Donate to Member
Re: Tortoise SVN and online repositories
« Reply #3 on: October 06, 2010, 07:45:41 PM »
Thanks, Deozaan.

Question: how do you identify what a "major" versus "minor" revision is?

Functionality. It's really very subjective though. In the Unix/server world, versions tend to go up slower than in the consumer-level end-user PC software world.
Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker

Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 7,038
    • View Profile
    • Just for mouser.
    • Donate to Member
Re: Tortoise SVN and online repositories
« Reply #4 on: October 06, 2010, 09:57:55 PM »
Question: how do you identify what a "major" versus "minor" revision is?

Functionality. It's really very subjective though. In the Unix/server world, versions tend to go up slower than in the consumer-level end-user PC software world.

Exactly. Whatever you think is a minor change, raise the minor version number. If you think it's kind of a big change but not a major change, go up a few minor version numbers (e.g. 1.0 to 1.5). And of course if you think you've made some major changes then go up a major version number.

That's just my opinion though. I don't know much about it since I don't release much software. Big software companies or actually just about any other person most likely do something else.

Take a look at mouser's version numbers.


barney

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,269
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Tortoise SVN and online repositories
« Reply #5 on: October 07, 2010, 07:42:17 PM »
Been a while, but when I was in the corporate atmosphere, I was give very strict - yeah, right! - guidelines on this topic.

The sequence required was version.subversion.revision.build, where
  • build was incremented any time the proggy was recompiled, usually for things like spelling corrections in error messages and such
  • revision was incremented any time, still using the error msg example, the error procedure was altered, e.g., the error trigger was adjusted
  • subversion was incremented when a significant change was made, e.g., a completely new error-handling routine, a different UI presentation
  • version was incremented whenever there was a major change, i.e., a totally new interface, a new approach to program application, and the like
However, I don't recall the folk who provided me with that dictum following it very closely  :D.

As mentioned, it's pretty much a case of personal preference.  Methinks the biggest reason for version.subversion.revision.build was to keep track of changes in a multi-developer/team environment, as well as for the bean counters to keep track and know when to charge for an upgrade or raise the price altogether  :(.


kyrathaba

  • N.A.N.Y. Organizer
  • Honorary Member
  • Joined in 2006
  • **
  • Posts: 3,087
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Tortoise SVN and online repositories
« Reply #6 on: October 08, 2010, 07:31:17 AM »
Hehe, thanks barney :)  That's about what I suspected.  Since I'm a one-man software-team, and since the current app I'm working on is liable to be used only by a very limited number of people, I won't worry too much.  Been working on it since August, and it's grown (in total, counting all modules) to over 4,000 lines of code.  I've gone from 1.0 to 1.3, so far...