[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

mantaining a shared library in subversion

From: Manuel López-Ibáñez <manuellopezibanez_at_yahoo.es>
Date: 2006-01-22 03:01:49 CET

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.