Hi,
(please CC me, I am not subscribed to the list)
I wish to maintain a library which will be shared by several projects
which are close related to each other and thus will share the same
repository.
I have read the latest version of Subversion book, however, there are no
clear hints on which is the best way to handle this scenario.
Assume this layout: (suggestions are welcome)
ProjectA/
trunk/
branches/
tags/
ProjectB/
trunk/
branches/
tags/
library/
trunk/
branches/
tags/
1) What is the best way to connect each project with the library. As I
understood, there are two methods: a) by using external definitions and
b) by using a mix of working copies.
In order to connect each project to a copy of the library using
externals definitions, I would create a directory for each project and
set svn:externals to point to library/trunk.
$ svn co svn://localhost/ProjectA/trunk
$ svn propset svn:externals .
library svn://localhost/library/trunk
Of course, I would prefer to use ../../library/trunk or either
/library/trunk to make explicit that it is the same repository. Will I
be able to fix this once relative paths are developed?
By using a mix of working copies I would use:
$ svn co svn://localhost/ProjectA/trunk
$ svn co svn://localhost/library/trunk library
However, I would require to do this always that I check out ProjectA,
wouldn't I? What other problems do you see in this approach?
2) Tagging.
By using external definitions I would create a tag of library and then
edit svn:externals to point to that tag.
$ cd library
$ svn cp . svn://localhost/library/tags/ProjectA-0.1
$ cd ..
$ svn propedit svn:externals .
library svn://localhost/library/tags/ProjectA-0.1
$ svn cp . svn://localhost/ProjectA/tags/0.1
However, by using a mixed working copy, I am actually able to make an
exact copy of the whole ProjectA including the library by creating a
complex tag as explained in the SVN book, isn't it?
$ cd ..
$ ls
ProjectA
$ svn cp ProjectA svn://localhost/ProjectA/tags/0.1
$ svn list svn://localhost/ProjectA/tags/0.1
...
library/
Actually, the latter seems a better way, since I don't have to remember
to update svn:externals. However, I am afraid I may be missing some
problematic details.
3) SVN commands (update, status, ci)
From the book[1], it seems that when using external definitions, svn
commands must be explicitly invoked for the "library/" directory. The
book seems to say that svn status will recurse into it, but svn commit
will not. What about svn update and other commands?
What is the situation when using a mixed working copy. If I run svn
status in ProjectA/, will I get the status of files within library/ ?
Will commit recurse into library/? What is the actual effect of that?
From the mails found on the mailing list [2][3], I got the impression
that external definitions are not very well-suited to maintain a shared
library within the same repository. Moreover, it seems that it is still
being developed [4] and won't be clearly defined soon.
Therefore, I would choose a mix of working copies as the best way to
handle this scenario. The only drawback is during checkout and this is
fine with me. However, I am afraid that I have misunderstood all the
implications of both methods, so perhaps you can cast some light on this
scenario.
Cheers,
Manuel.
[1] http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
[2] http://svn.haxx.se/users/archive-2005-01/0737.shtml
[3] http://svn.haxx.se/users/archive-2005-01/0057.shtml
[4] http://svn.haxx.se/users/archive-2005-01/1410.shtml
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 23 01:15:29 2006