>>> On Sat, Dec 2, 2006 at 11:39 PM, in message
<211166.90338.qm@web90401.mail.mud.yahoo.com>, "T. Nguyen"
<ptn_y2k1@yahoo.com>
wrote:
> Hi,
>
> I am setting up a Subversion server. As I read several books and
searched
> on the internet, I have not seen any complicated repository structure
as my
> workplace requested. Please see the following structure:
>
> svn_root
> dev
> project1_root
> project1_web
> project1_web_v1
> trunk
> tags
> branches
> project1_web_v2
> (trunk, tags,
branches)
> project1_jobs
> project1_jobs_v1
> (trunk, tags,
branches)
> project1_jobs_v2
> (trunk, tags,
branches)
> project2_root
> .....
> .......
> .......
> ........
> project3_root
> qa
> ................(same structure as dev)
>
> Here are my questions that I need your helps.
>
> 1. Is it possible to have that kind of structure in Subversion? If
yes, is
> it a good or bad structure? And is it easy to maintain later? If no,
please
> give me your advise what I should do?
I think you need to ask your self and maybe your co-workers this
question:
Do we code to a feature or do we code to a series of milestones?
You may be wondering what this has to do with Subversion, but this
question is more about how your team(s) work and develops.
If you code to a feature, then your trunk will always be a 'stable'
trunk. That is the trunk will always compile or run. You always
develop a feature in a branch an then merge that feature into the trunk.
From there a tag is usually created to depict if that point of the
trunk is a dev revision or qa revision or even a production revision.
If you code to a milestone, then your trunk will always be an
'unstable' trunk. That is all features, requirements, etc are committed
to the trunk. The trunk may not always compile or run, but once
everything does compile and/or run for a given milestone, then a branch
is created to depict that mile stone. A branch is a representation of a
milestone or series of milestones such as version 1.1, 1.2, 2.0 and 2.5,
and so on. You might change a something in a branch to create a patch
or an update, but you'll be able to bring those changes back to the
trunk if need be. Generally then the tags directory depicts a dev, qa,
or prod revision of that 'release' branch. This is the simple approach
to 'unstable' trunk. You can also use 'unstable' trunk to take features
from the trunk and merge them into a branch (like the Subversion
developers do with Subversion source code), but it take strong and well
understood process to make that work.
Now I see from your directory structure that 'web technologies' are
involved. In my experience, that usually means you're constantly doing
changes for bug fixes and creating new features. These often go out as
soon as they are ready and generally don't wait on any other feature
unless there is a dependency. If that is the case, consider the
'stable' trunk approach.
In regards to your structure: Differentiating QA and DEV at such a high
level is unnecessary since Subversion does atomic commits and all
revision numbers are global across the repository. My suggestion, use
the tags folder as a way to track dev and qa for each project if a human
readable value needs to be placed on a revision number. Furthermore,
separating projects across the QA and DEV is just as tough, especially
if they are not in the same repository created with 'svnadmin create'.
Besides, it easier to know everything with a project is in that one
directory rather than scattered across a single repository under
multiple directories (dev, qa, prod, etc). If you separate 'dev' 'qa',
and 'prod' into different repositories, while possible, it will be very
painful to keep them in sync.
A combination of the above 'stable' and 'unstable' trunk can be done,
but I strongly suggest make sure everyone (developers, managers, QA,
etc) all completely understand what each branch does. Have very good
documentation created and up to date to get new developers or employees
up to speed about your repository quicker.
If version 1 and 2 of each project are significantly different and
continual active development is being done with each version, then yes,
separate them as you have shown above. If all active development is
only on the latest version, Use the same trunk and take the 'unstable'
trunk approach towards development.
> 2. If it's possible, which level should I use 'svnadmin create' and
which
> level should I use 'svn mkdir'?
You should use the 'svnadmin create' command at the 'svn_root' point if
you use the above structure. If you don't separate dev, qa, and prod,
you could use the 'svnadmin create' command for each project root then.
By separating various points (dev, qa, prod) with different
repositories, you'll find it very painful to synchronize all the
repositories.
>
> I am looking forward to receiving your response. Thank you very
much.
>
> Regards,
> Tracy
>
>
>
>
>
>
> ---------------------------------
> Have a burning question? Go to Yahoo! Answers and get answers from
real
> people who know.
If your not pressed for time to get this implemented, I strongly
suggest getting a consultant who understands Subversion inside and out
to come in. Discuss your development strategy, but more importantly
goals with them, but make sure everyone understands this: Going to
Subversion may require changes to the development process.
Make sure everyone involved in the repository structure decision
understands that Subversion is not exactly like CVS, Perforce, VSS,
ClearCase, etc... Subversion is extremely flexible and will let you
accomplish any type of development methodology, but there are some
limitations that will not let it behave exactly like CVS, Perforce, VSS,
ClearCase, etc... Subversion is a different mind set and your
development process must adjust according and usually for the better of
all involved.
Good luck,
Johnathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 4 17:26:52 2006