Re: Seeking advice on versioning

On 12/15/06, Jim Reynolds <jim.jreynold@gmail.com> wrote:
> Hello,
>
> I have subversion installed on a PC running XP. I am working on a
> e-commerce web site, and need some advice.
>
> I have just completed my first project (ecommerce site) and want to
> put the code into subversion and (tag or branch it).So this is my
> first question. What do I do with the first initial set of code that I
> am checking in? Do I tag it or branch it?
>
> Now, I want to keep that there, and I believe branch that code to
> start working on revision2 of the first set of code. Am I correct in
> my logic here?
>
> Then if any bugs come in for version1, do I need to make changes in
> both sets of code?
>
> As you may see, I am a bit confused on how to implement code
> management? Are there any articles or SOPs on this?

My expectation (given I'm a CVS user evaluating SVN) would be something like...

On release of 1.0 tag the code. copying .../trunk to .../tags/1_0

Continue working on the trunk towards 2.0 (or a 2.0 milestone)

When you need to maintain 1.0 find the revision number by using the
log command and the 'stop on copy' option.

Branch that revision of .../trunk to .../branches/1_0_fixes

You may find you want to merge 1_0_fixes back to trunk. Read up on merging.

Once you've completed the fixes to an acceptable level for release you
tag by copying .../branches/1_0_fixes to .../tags/1_0_1

You may, at that stage choose to 'close' the branch by deleting
.../branches/1_0_fixes.

Hopefully this process is consistent with what experienced Subversion
users might suggest. If not, I'm keen to hear corrections before we
start down this track ourselves.

Incidentally, you may want to consider other activities in your
development path:

- Once you have multiple developers you may want feature branches
rather than always developing the next version on the trunk. This
requires thinking about backporting (merging from the trunk to the
branches occasionally) as well as the merging process.
- You also might want a formal beta period and therefore might create
QA branches prior to tagging a release.

Below is just a taster of using the flexibility of subversion to
better organise tags and branches.

.../
  tags/
    betas/
    milestones/
    releases/
  branches/
    qa/
    maintenance/
    features/

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org