You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bojan Resnik <re...@swissinfo.org> on 2004/09/10 21:52:21 UTC
Project Organization
Hello,
I am new to Subversion, having used VSS in the past. I have read the
Subversion book, and I like the Subversion way of doing things.
However, I am having thoughts about reorganizing the projects, and
there is a conceptual issue which I cannot seem to resolve. Currently,
all the projects are in a single VSS database, but it seems to me that
it would be beneficial if each had its own Subversion repository. The
problem is that there is set of common projects, and all other
projects depend on at least one of these. The structure is similar to
this:
- shared
- sh1
- sh2
...
- project1
- project2
...
Both project1 and project2 depend on sh1, while some other
root-level projects have their own dependencies among the shared
projects.
Conceptually, it seems that all shared projects should go into one
repository, and every project into a repository of its own. But,
Subversion commands work only within a repository, so working with
this layout would be a maintenance nightmare... Branching for a
release version would include branching from two repositories, and
many other tasks would require keeping track of two (or more) revision
numbers of different repositories... Or maybe I have misunderstood
something?
Did anyone have similar problems, and what solution did you come up
with?
Regards,
Bojan Resnik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Project Organization
Posted by William Nagel <bi...@stagelogic.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> If I understand correctly, even with the svn:externals property, I
> would have to somehow match revision numbers of shared projects and
> applications.
>
> Say this is the organization:
> - rep1/shared
> sh1
> sh2
>
> - rep2/project1
>
> Now, when I need revision 341 of project1 repository, I must be
> aware that it
> used revision 15 of shared repository. If there are other repositories
> (like separate repositories for each third party library), the number
> of revisions to track will increase. Is my understanding correct, or
> can this be automated in some way?
You can store a specific repository revision in the svn:externals
property, so that every time you check out that revision you will get
the correctly matching shared project revision. On the other hand,
that can get fairly unwieldy if the the shared project changes often,
but it might be practical for tags (so, in the main trunk you could
keep the svn:externals property without a specific revision, so it
refers to the head, but then when you tag it, change the property to
refer to a specific revision---it probably wouldn't be too hard to
write a script for creating a tag that would do both steps together,
automatically).
- -Bill
>
> Regards,
> Bojan Resnik
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBQ0GXSwe0AHUdEwQRAt/NAKCRv2ucDYM9i2b6oewDxr6AxyoCNwCeNveh
DUu+Z50uVeCzZzFYaH8ZXnI=
=bWEU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: Project Organization
Posted by Bojan Resnik <re...@swissinfo.org>.
WN> Hi Bojan,
WN> Why are you considering using multiple repositories? Server
WN> performance or logical separation?
WN> If you are doing it for logical separation, you might consider just
WN> putting the different projects into different top-level directories.
WN> Then, individual developers can checkout just the directory for the
WN> project they're working on, but branching and tagging can easily be
WN> done across multiple projects if desired.
WN> You might also want to look at the svn:externals property, which is
WN> described in fairly high detail in the Subversion book. Using
WN> externals to link a project to other projects may be sufficient for
WN> what you want to do.
WN> - -Bill
If I understand correctly, even with the svn:externals property, I
would have to somehow match revision numbers of shared projects and
applications.
Say this is the organization:
- rep1/shared
sh1
sh2
- rep2/project1
Now, when I need revision 341 of project1 repository, I must be aware that it
used revision 15 of shared repository. If there are other repositories
(like separate repositories for each third party library), the number
of revisions to track will increase. Is my understanding correct, or
can this be automated in some way?
Regards,
Bojan Resnik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: Project Organization
Posted by Bojan Resnik <re...@swissinfo.org>.
WN> Hi Bojan,
WN> Why are you considering using multiple repositories? Server
WN> performance or logical separation?
WN> If you are doing it for logical separation, you might consider just
WN> putting the different projects into different top-level directories.
WN> Then, individual developers can checkout just the directory for the
WN> project they're working on, but branching and tagging can easily be
WN> done across multiple projects if desired.
The book got me thinking about the logical separation of the
projects, the current approach is exactly what you suggest - and the
only possible way with VSS. I was thinking that perhaps it everything
could be broken up to be less monolithic, yet have the same ease of
use.
WN> You might also want to look at the svn:externals property, which is
WN> described in fairly high detail in the Subversion book. Using
WN> externals to link a project to other projects may be sufficient for
WN> what you want to do.
WN> - -Bill
Thanks, I will look into that.
Regards,
Bojan Resnik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Project Organization
Posted by William Nagel <bi...@stagelogic.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Bojan,
Why are you considering using multiple repositories? Server
performance or logical separation?
If you are doing it for logical separation, you might consider just
putting the different projects into different top-level directories.
Then, individual developers can checkout just the directory for the
project they're working on, but branching and tagging can easily be
done across multiple projects if desired.
You might also want to look at the svn:externals property, which is
described in fairly high detail in the Subversion book. Using
externals to link a project to other projects may be sufficient for
what you want to do.
- -Bill
On Sep 10, 2004, at 4:52 PM, Bojan Resnik wrote:
> Hello,
>
> I am new to Subversion, having used VSS in the past. I have read the
> Subversion book, and I like the Subversion way of doing things.
>
> However, I am having thoughts about reorganizing the projects, and
> there is a conceptual issue which I cannot seem to resolve. Currently,
> all the projects are in a single VSS database, but it seems to me that
> it would be beneficial if each had its own Subversion repository. The
> problem is that there is set of common projects, and all other
> projects depend on at least one of these. The structure is similar to
> this:
>
> - shared
> - sh1
> - sh2
> ...
> - project1
> - project2
> ...
>
> Both project1 and project2 depend on sh1, while some other
> root-level projects have their own dependencies among the shared
> projects.
>
> Conceptually, it seems that all shared projects should go into one
> repository, and every project into a repository of its own. But,
> Subversion commands work only within a repository, so working with
> this layout would be a maintenance nightmare... Branching for a
> release version would include branching from two repositories, and
> many other tasks would require keeping track of two (or more) revision
> numbers of different repositories... Or maybe I have misunderstood
> something?
>
> Did anyone have similar problems, and what solution did you come up
> with?
>
> Regards,
> Bojan Resnik
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBQiXDSwe0AHUdEwQRAiSbAKDN64N8RSqTYuuKMz4+GU+1ObiqpACgrMxY
z6ISb/BQ+WVodrv3uE8AloQ=
=Ib93
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org