On 11/16/2010 3:52 AM, Neson Maxmelbin (RBEI/EMT5) wrote:
> Hello .
> I want to setup a reliable development process for SVN in our environment.
> Here is what I am planning to propose for the process.
>
> Each project in the repository will have the following folders -
> -branches
> -tags
> -trunk
> The initial baseline of the project will be in /trunk/ folder.
> For the first Release, the trunk is checked out , changes made and then
> commited into trunk.
> It should then be tagged into the /tags /folder as Release_/xyx ./
> The tag Release_/xyz /is then considered as baseline for the next Release.
> For the next Release, developers should checkout from the tag
> Release_/xyz /.
> Make the necessary code changes.
> Switch to /trunk/
> Commit changes to trunk
> After all changes are done, Integrator tags the HEAD revision to a new
> tag Release_/xyz2/
> -------------
> My questions -
>
> * Does this sound like a common procedure followed by SVN users and
> is it reliable?
Not quite, but I think another response has addressed how to merge
things and that you normally don't check tags out for further
development. Also, note that a 'switch' does an implicit update of your
workspace to the new target so it won't work quite like you seem to expect.
> * Do you foresee any issues with this process
There are two common styles of development and you should consider which
you want to follow before starting. One is to do nearly all development
on the trunk, branching for new work only when planning disruptive or
experimental changes that you want to isolate from others. Then as you
approach what may be release points you copy to a branch for final
testing and revisions that may be specific to this release - and you may
copy to tags for testing and potential release versions. Any
maintenance work on this release would continue on this release branch.
This lets you support multiple concurrent released versions while
everyone has easy access to each others' new work on the trunk.
The other style is to always have a clean copy of the latest release on
the trunk while development happens on one or more branches. This might
be more appropriate for a public-facing site where people always expect
to be able to check out the trunk and get a tested/working version.
> * How can I prevent people from commiting into tags
> * Can I lock a tag?
This is mostly convention. As far as svn is concerned directories are
all the same, although you can use hook scripts to control modifications
if you want. Normally you just wouldn't check out a tag for
modification. If you didn't follow a work flow that always creates a
branch copy for work before copying on to the tag, you can copy a tag to
create the branch if you need to use it as a starting point.
> * While tagging I get options for "Create copy in Repository from"
> 1> Head revision from Repository , 2> Specific revision from
> repository 3> Working copy . I always choose the first option. Is
> it correct?
Maybe... It would be safer to commit your changes, then use the
resulting revision as the copy source. If you take HEAD, you might get
a revision someone else just committed with changes you don't know about
and if you use the working copy you can accidentally pick up files that
haven't been committed elsewhere.
> * With regards to the tags, does the SVN repository maintain a full
> copy or only a delta copy ?
From the client's perspective it always looks like a full copy no
matter what you check out, but differences between revisions in the
repository may be deltas and things that are copied are just different
names for the same items.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-11-16 17:20:42 CET