<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 01/03/2012 4:47 PM, Pietro Moras wrote:
    <blockquote cite="mid:SNT133-W481BDB3444F60429D8E9F8EF6C0@phx.gbl"
      type="cite">
      <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
      <div dir="ltr">
        <p style="margin-bottom: 0cm;" class="western" lang="en-US"><font
            size="2">Hi,</font></p>
        <p style="margin-bottom: 0cm;" class="western" lang="en-US">    
          <font size="2">Having
            to develop two distinct, un-related Projects, I wonder
            whether it is
            sensible to store them both into a unique Subversion
            Repository, or it is
            natural to create two distinct Repositories, each one
            dedicated to a
            unique Project.</font></p>
        <p style="margin-bottom: 0cm;" class="western" lang="en-US"><br>
          <font size="2">In
            other words, a Subversion Repository is naturally meant for
            more than
            one, unrelated, independently versioned project, or not?</font></p>
        <p style="margin-bottom: 0cm;" class="western" lang="en-US"><font
            size="2">Thanks.
            Yours,<br>
             </font><font size="2">-
            P.M.</font></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Eric mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Eric@riverbankcomputing.com">Eric@riverbankcomputing.com</a>
<a class="moz-txt-link-freetext" href="http://www.riverbankcomputing.com/mailman/listinfo/eric">http://www.riverbankcomputing.com/mailman/listinfo/eric</a>
</pre>
    </blockquote>
    In general I would take the approach that one project = one
    repository, is eases things like ticketing, etc., but if there is
    code in common you might like to consider a third repository for
    common code, (accessed by externs in the respective project specific
    repositories).  Such a set up is far easier to run.  If both
    projects are released as a single package you might also like to
    consider a master, release project with things like package build
    scripts, documentation, etc., in.  In this case you will probably
    end up with a top level package with extern references to two, or
    more, project repositories, each with possibly extern links to a
    common repository.<br>
    <br>
    I know of a number of commercial packages using subversion that use
    a similar structure.<br>
    <br>
    Gadget/Steve<br>
  </body>
</html>