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