[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Seeking advice on versioning

From: John Allen <john.allen_at_codemountain.net>
Date: 2006-12-16 19:47:00 CET

Talden wrote:
> 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.
No need to do this, instead just copy the 1.0 tag to branches

eg. svn copy svn://host/path/tags/1_0 svn://host/path/branches/1_0

Then switch you working copy with

svn switch svn://host/path/branches/1_0
> 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

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 18 15:28:38 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.