You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Elliott Hughes <en...@jessies.org> on 2005/03/03 13:32:58 UTC
svn mv between repositories
A friend who's used neither Subversion nor BitKeeper recently asked me
what I don't like about Subversion. There were two things that stood out,
if you ignore the central repository debate.
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?)
--
Elliott Hughes, http://www.jessies.org/~enh/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn mv between repositories
Posted by ycdtosa <yc...@eupla.unizar.es>.
Dale Worley wrote:
>That is correct. To work with multiple repositories, you need the fixes
>that we (at Pingtel) have made but not checked in...
>
>Dale
>
>
>
Dale, i'm wordless again! i'll have to learn to use svncopy.pl
ASAP, so i'm ready for your changes whenever those come.
Thanks
- ycdtosa
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn mv between repositories
Posted by Dale Worley <dw...@pingtel.com>.
> From: ycdtosa [mailto:ycdtosa@eupla.unizar.es]
>
> But (even without testing at all, just from the README) it
> doesn't seem
> like working between across diferent repositories. (I'll
> check that from
> a machine with perl installed)
That is correct. To work with multiple repositories, you need the fixes
that we (at Pingtel) have made but not checked in...
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn mv between repositories
Posted by ycdtosa <yc...@eupla.unizar.es>.
Dale Worley wrote:
>Actually, they're easy to use *provided* you don't expect "svn copy" to
>work. You really have to use svncopy.pl, because only it allows you to
>specify the additional information needed to understand what you mean by
>copying.
>
>
>
from svncopy.pl README:
Overview
========
This script performs an svn copy command. It allows extra processing to get
around the following limitations of svn copy:
svn:externals definitions are (in Subversion 1.0 and 1.1 at least) absolute
paths. This means that an svn copy used as a branch or tag operation on a
tree with embedded svn:externals will not do what is expected. The
svn:externals will still point at the original location and will not be
pinned down.
[... and much more!]
wow. Someone did read my mind even before i thought about this.
You wizards of the subverground!
Thanks Dale, I didn't know about svncopy.pl.
But (even without testing at all, just from the README) it doesn't seem
like working between across diferent repositories. (I'll check that from
a machine with perl installed)
- ycdtosa
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn mv between repositories
Posted by Dale Worley <dw...@pingtel.com>.
> From: ycdtosa [mailto:ycdtosa@eupla.unizar.es]
>
> 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.
Actually, they're easy to use *provided* you don't expect "svn copy" to
work. You really have to use svncopy.pl, because only it allows you to
specify the additional information needed to understand what you mean by
copying.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn mv between repositories
Posted by ycdtosa <yc...@eupla.unizar.es>.
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
RE: svn mv between repositories
Posted by Dale Worley <dw...@pingtel.com>.
> 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.
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.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org