If your product projects will have independent release cycles, you
definitely should choose option B. Otherwise you will not be able to
have separate bug fix branches etc...

How would you like to resolve the according artifact of the common
project?
If you are using a maven repository as well, maven will do the job for
you without any extra effort as soon as you deploy the according
artifact to the maven repository...
And with a little naming convention for Tags you can relate common
project tags with specific product project tags...

Regards,
CAK

Am 18.09.2009 um 17:05 schrieb Doug Leeper:

We have been using CVS for a long time now and want to move to SVN.
We have an empty SVN repository created but have questions on how we
should set up our multiple projects that all utilize a common
project in conjunction with tags, branches, releases.

To keep things somewhat consistent between the CVS/SVN, we know we
want to first separate between python and Java (our 2 development
languages).  I believe our first SVN decision would be to have two
separate repositories for these technologies and have multiple
projects in these repositories.  FYI: Java and Python are completely
separate code bases, are not dependent upon one another, and have a
different release.

Now within each of these repositories, we both have a common utility
project and multiple product projects.  When we release/tag a
product, we would like to release/tag only the common and specific
product (or does it matter?).

We have done some research SVN but are looking for best practices
based on our requirements.  We were hoping that someone might be
able to point us in the right direction/place of information on
achieving a manageable/effective source repository and build
management.

I have reviewed Wicket's project hierarchy and seems relevant to
ours.  However, when wicket is built/released, all projects are
tagged and built which is contrary to our goal.

We use Maven and its project structure.  Our common project is a
referenced module in each product project.

Which of the following options is recommended?
Are there any good specific references that would help determine
this?  (we have googled but a lot of information is returned)
I did find this link which was helpful: http://svnbook.red-bean.com/en/1.1/ch05s04.html
 which is why we are leaning towards Option B.

Option A:

<repo>/java
    + trunk
           + common
           + project 1
           + project N
    + tags
           + common
           + project 1
           + project N
    + branches
           + common
           + project 1
           + project N
    + releases
           + common
           + project 1
           + project N

Option B:

<repo>/java
      + common
            + trunk
            + tags
            + branches
            + releases
      + project 1
            + trunk
            + tags
            + branches
            + releases
      + project N
            + trunk
            + tags
            + branches
            + releases

Option C: (this option is a separate repo for each project)

<repo>/java/common
        + trunk
        + tags
        + branches
        + releases
<repo>/java/project1
        + trunk
        + tags
        + branches
        + releases
<repo>/java/project2
        + trunk
        + tags
        + branches
        + releases


Thanks in advance!
- Doug

--
Carsten Kaiser
Principal Consultant
mailto:carsten.kai...@valtech.de
Mobile: +49 170 5270206

Valtech GmbH
Werner-Heisenberg-Straße 2
63263 Neu-Isenburg
Germany

Phone: +49 6102 88468-0
Fax: +49 6102 88468-28

http://www.valtech.de

Geschäftsführer: Ingo Kriescher
Amtsgericht Düsseldorf HRB48672

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to