You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bill Mill <bi...@gmail.com> on 2006/12/18 22:50:32 UTC
Tagging With Multiple Projects And One Common Library In The Same Repo
Here's a rough sketch of our repository:
/project.root
/Apps
/app1
/branches
/tags
/trunk
/app2
/branches
/tags
/trunk
/Common
/branches
/tags
/trunk
ATM, all applications statically compile in the source of "Common", because it's
under very heavy development. (I plan to change this once it stabilizes, but
assume that this is unchangeable for now.)
The question is, how should I create a Tag for version 1 of app1, such that it
includes Common in some way?
After much discussion of svn:externals, various branching schemes, and other
weirder ideas, a fellow programmer and I decided that the best answer was to
copy the app1 release into app1/tags/version1 , then copy /Common/trunk into
app1/tags/version1/commonlib .
Is this the way you would do it? Is there a better way?
You may either assume that repo structure is fixed, or argue that there's a
structure which is *so* better that it justifies the cost of rearranging
everything - both are valid.
The only 2 requirements are that I can
a) build app1/tags/version1 10 months from now, and
b) svn diff app1/tags/version1 app1/tags/version2
Thanks for any ideas,
Bill Mill
bill.mill at gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Tagging With Multiple Projects And One Common Library In The Same Repo
Posted by Abhinandan Jain <ja...@helios.jpl.nasa.gov>.
Bill
We have a more somewhat general situation. Our software contains a
collection of modules in SVN. We have multiple product applications that
use different combinations of the modules. That is, modules are shared
across the different applications. For such sharing to work, we find
that it is critical to use a 2-tier approach to track and tag the
evolution of the software - both at the component module level as well
as at the application level.
Each module's software development is managed in very much the
branch/tags/trunk structure you describe. Our application definition
however is very lightweight. An application is simply a clearly defined
combination (via a config file) of the modules it needs. For practical
purposes, an application is simply a configuration file that lists its
modules and their tagged versions. Given such a configuration file, we
have a mechanism to checkout the required modules to create an
application specific sandbox. Application version evolution consists of
the evolution of its configuration file, i.e. an application evolves in
time by using different versions of the modules. Arbitrary combinations
of modules will typically not work togethger - and application tags are
ways of tracking configuration files that list the module version
combinations that do work together. So releases are made both at the
module as well as the application level.
Basically, we found that we could not fully solve the problem of sharing
code across applications all within SVN (or CVS). However SVN gets us a
long way there. We have an additional collection of Perl scripts -
collectively known as YaM - that when used with SVN as described above,
allows us to manage multiple application products that share
software. YaM originally worked with CVS but now supports SVN as
well. You can read find out more about it at
http://dartslab.jpl.nasa.gov/yam and/or read the paper at
http://dartslab.jpl.nasa.gov/References/pdf/2006-yam-smcit.pdf.
If there is interest I can look into making YaM more easily available.
Abhi
On Mon, Dec 18, 2006 at 10:50:32PM +0000, Bill Mill wrote:
> Here's a rough sketch of our repository:
>
> /project.root
> /Apps
> /app1
> /branches
> /tags
> /trunk
> /app2
> /branches
> /tags
> /trunk
> /Common
> /branches
> /tags
> /trunk
>
> ATM, all applications statically compile in the source of "Common", because it's
> under very heavy development. (I plan to change this once it stabilizes, but
> assume that this is unchangeable for now.)
>
> The question is, how should I create a Tag for version 1 of app1, such that it
> includes Common in some way?
>
> After much discussion of svn:externals, various branching schemes, and other
> weirder ideas, a fellow programmer and I decided that the best answer was to
> copy the app1 release into app1/tags/version1 , then copy /Common/trunk into
> app1/tags/version1/commonlib .
>
> Is this the way you would do it? Is there a better way?
>
> You may either assume that repo structure is fixed, or argue that there's a
> structure which is *so* better that it justifies the cost of rearranging
> everything - both are valid.
>
> The only 2 requirements are that I can
> a) build app1/tags/version1 10 months from now, and
> b) svn diff app1/tags/version1 app1/tags/version2
>
> Thanks for any ideas,
> Bill Mill
> bill.mill at gmail.com
>
> ---------------------------------------------------------------------
> 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
Re: Tagging With Multiple Projects And One Common Library In The Same Repo
Posted by Bill Mill <bi...@gmail.com>.
On 12/19/06, Thomas Hemmer <th...@go-engineering.de> wrote:
> Bill,
>
> I personally would prefer a structure like
>
[... one /tags for all apps]
>
> assuming your app1, app2, ..., appN together form one deployable
> product.
That would be much nicer, but unfortunately they're all on separate
release schedules. We talked about doing that, but we're worried that
it's too space inefficient, and deleting all the unnecessary apps
every time would be error-prone and just kind of annoying.
>
> Another scenario could be that app1, app2, ..., appN each are separate
> products; in this case I would propose the following scheme:
>
> /project.root
> /branches
> /tags
> /app1
> /1.0
> /app
> /common
> /1.1
> /app
> /common
> ...
> /app2
> /1.0
> /app
> /common
> /1.1
> /app
> /common
> ...
> /trunk
> /app1
> /app2
> /Common
>
Why have the tags at the top-level? It seems to me, semantically, that
the tags are of an application, and thus should be in a subfolder of
its application's parent folder.
On the other hand, that structure does seem to make branching match
more simply with what we're doing.
Thanks
Bill Mill
bill.mill at gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Tagging With Multiple Projects And One Common Library In The Same Repo
Posted by ka...@mindspeed.com.
news <ne...@sea.gmane.org> wrote on 12/18/2006 02:50:32 PM:
> Here's a rough sketch of our repository:
>
> /project.root
> /Apps
> /app1
> /branches
> /tags
> /trunk
> /app2
> /branches
> /tags
> /trunk
> /Common
> /branches
> /tags
> /trunk
>
><<<snip>>>
>
> The question is, how should I create a Tag for version 1 of app1, such
that it
> includes Common in some way?
>
> After much discussion of svn:externals, various branching schemes, and
other
> weirder ideas, a fellow programmer and I decided that the best answer
was to
> copy the app1 release into app1/tags/version1 , then copy /Common/trunk
into
> app1/tags/version1/commonlib .
>
> <<<snip>>>
This reminds me of the "complex tags" scenario described at
<http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html#svn.branchmerge.tags.mkcomplex>
. You can create a working copy that contains a combination of revisions
(by using `svn update`) and branches (by using `svn switch` on certain
directories). If you can get a working copy to look exactly as you like,
then you can copy the working copy to the appropriate URL on your server.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Tagging With Multiple Projects And One Common Library In The Same Repo
Posted by Thomas Hemmer <th...@go-engineering.de>.
Bill,
I personally would prefer a structure like
/project.root
/branches
/tags
/1.0
/app1
/app2
/common
/1.1
/app1
/app2
/common
...
/trunk
/app1
/app2
/Common
assuming your app1, app2, ..., appN together form one deployable
product.
Another scenario could be that app1, app2, ..., appN each are separate
products; in this case I would propose the following scheme:
/project.root
/branches
/tags
/app1
/1.0
/app
/common
/1.1
/app
/common
...
/app2
/1.0
/app
/common
/1.1
/app
/common
...
/trunk
/app1
/app2
/Common
Nevertheless I am curious about other ideas that anyone else might have
out there ;-)
Best regards,
Thomas
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Bill Mill
> Sent: Monday, December 18, 2006 11:51 PM
> To: users@subversion.tigris.org
> Subject: Tagging With Multiple Projects And One Common
> Library In The Same Repo
>
> Here's a rough sketch of our repository:
>
> /project.root
> /Apps
> /app1
> /branches
> /tags
> /trunk
> /app2
> /branches
> /tags
> /trunk
> /Common
> /branches
> /tags
> /trunk
>
> ATM, all applications statically compile in the source of
> "Common", because it's under very heavy development. (I plan
> to change this once it stabilizes, but assume that this is
> unchangeable for now.)
>
> The question is, how should I create a Tag for version 1 of
> app1, such that it includes Common in some way?
>
> After much discussion of svn:externals, various branching
> schemes, and other weirder ideas, a fellow programmer and I
> decided that the best answer was to copy the app1 release
> into app1/tags/version1 , then copy /Common/trunk into
> app1/tags/version1/commonlib .
>
> Is this the way you would do it? Is there a better way?
>
> You may either assume that repo structure is fixed, or argue
> that there's a structure which is *so* better that it
> justifies the cost of rearranging everything - both are valid.
>
> The only 2 requirements are that I can
> a) build app1/tags/version1 10 months from now, and
> b) svn diff app1/tags/version1 app1/tags/version2
>
> Thanks for any ideas,
> Bill Mill
> bill.mill at gmail.com
>
> ---------------------------------------------------------------------
> 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