Re: Maintaining separate revision numbers for dependent projects

If you enforce a release mechanism rather than a HEAD code-sharing
mechanism then when you have

   ProjectY uses ProjectX

You don't have new ProjectX code affect ProjectY until PrjectY
developers merge in that code. IE don't reference X code directly but
either reference the build artifacts of a given build of X or a copy
of the X source structure (properly noted of course).

EG in the subprojects as libraries it might be

Y/
  trunk/
    src/
    libs/
      local/
        x.3.0.1.jar
      3rdparty/

Or you can just share the code

Y/
  trunk/
     src/
       local/
       shared/
          X/
     lib/

X/ in this case is a copy of the X structure that is merged into when
Y accepts a new build of X. Prevents project dependencies and means
not all projects must move forward at the same time.

What do other people do when sharing code between projects with what
should be independent (or at least loosely coupled) release cycles.

Having them dependent is bad in the case where Y and Z both need X...
Y needs a new function in X that requires a refactor. Z is now forced
to adopt the new X code and make its own refactoring even if it
doesn't benefit from the new change.

--
Talden
On 16/11/06, Matthew Kidd <Matthew.Kidd@cappsdigital.com> wrote:
> As it's been described to me the revision numbers for each project do matter. I neglected to mention that each subproject would indeed have it's own branches, tags, and trunk folders.
>
> Could you expound on the release mechanism point?
>
> I'm not well versed in Ant but that is what we used for builds. I'd have to check with our build coordinator to see if we do separate the projects can the build file be changed to reference each seperate project folder. But I have a feeling my manager will be adamant about keeping the directory structure the way it is.
>
> Matt
>
>
> >>> Talden <talden@gmail.com> 11/14/06 10:07 pm >>>
> Well, in a single repository there's no way you can have independent
> revisions.  Are you sure that revision numbers matter to you in that
> way though.
>
> There's nothing stopping you keeping the structure as you have it
> however you'll probably want trunk, branches and tags folders for each
> sub project.
>
> If there are project dependencies then you need to decide whether you
> use a release mechanism between sub-projects or just have their builds
> refer to some non-version controlled build outputs (meaning you need
> to build the sub-projects in dependency order).
>
> --
> Talden
>
> On 15/11/06, Matthew Kidd <Matthew.Kidd@cappsdigital.com> wrote:
> > Hi,
> >
> > My team is beginning a project tomorrow for a complex project in which 3 separate code bases form the basis of the overall project. Each code base operates a different facet of the application but in the current CVS the hieracrhy is as such:
> >
> > project A
> >    |
> >    |
> >    |
> >    |Subproject A
> >         |
> >         |
> >         |
> >         |Codebase
> >    |
> >    |
> >    |
> >    |Subproject B
> >         |
> >         |
> >         |
> >         |Codebase
> >    |
> >    |
> >    |
> >    |Subproject C
> >         |
> >         |
> >         |
> >         |Codebase
> >    |
> >    |
> >    |
> >    |more pertinent files and folders
> >
> > Now as I was saying before each of these code bases is dependent on the other but can function separately. I'm trying to maintain as much of the previous project structure as possible but as I'm sure you're all away, if I were to put project A in SVN the subprojects would all have the same revisions even if those code bases are stable.
> >
> > Does anyone know how I can maintain the above project hierarchy for porject A yet have independent revisions for the subprojects?
> >
> > Matthew Kidd
> >
> >
> > ---------------------------------------------------------------------
> > 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