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

Re: svn mv between repositories

From: ycdtosa <ycdtosa_at_eupla.unizar.es>
Date: 2005-03-08 23:08:12 CET

Dale Worley wrote:

>>From: Elliott Hughes [mailto:enh@jessies.org]
>>
>>The main annoyance is this: as mentioned in
>>[http://subversion.tigris.org/faq.html#multi-proj], "'svn
>>cp/mv' currently
>>only works within a single repository". This is a real bummer
>>if you went
>>for the one-repository-per-project option. Why isn't there an
>>issue in the
>>issue tracker for this? (If there is, and I just couldn't find it, why
>>isn't there a link from the FAQ?)
>>
>>
>
>IMHO, there are two main reasons. The first reason is that the svn:external
>feature makes it quite convenient to have one copy of any "infrastructure"
>code shared among projects that live in other repositories.
>
>
I don't think svn:external are easy to use. Using svn:external gets
tricky if you want to
get an "exact copy" of the project, for that you must make all your
svn:externals
sticky when tagging, so the svn:externals point to a specific revision
of the
other project subtree. ;-). You may also tag all the projects involved and
change the svn:externals to point to the new tags.

Its just a thought but...
would it be easy to implement svn cp in such a way that it could manage
the svn:externals for you?
like if you do:

> svn mv svn://server/p1/trunk/somefolder svn://server/p2/trunk/libs/pp
so it created
 svn:external "pp svn://server/p1/trunk/somefolder" at
svn://server/p2/trunk/libs/

>The second reason is one that we've been coming up against in our software,
>namely that the "separate repository for each project" organization works
>less well than you'd think. In practice, having a bunch of projects in one
>repository has little or no additional overhead. But if they share *any*
>code, it suddenly becomes annoyingly awkward, as exporting a particular
>version and other operations become operations on multiple repositories.
>
>
I agree on that... and maybe this should be pointed out somewhere on the
book.

The only advantages i can think of about working with the
one-repository-per-project layout is,
and i need the second one.
1.- shorter url-names
2.- one-validation-per-project (while accessing via svnserve)

On the other hand.. yeah svn:external should do the work,
and IIRC, svn:external is a versioned property.

>Dale
>
>
>

>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>

-- 
Mark Parker: "The fact that compressed xml is a well-known proprietary binary format 
              doesn't make it less proprietary or less binary."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 8 23:16:15 2005

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.