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

Re: svn copy driving me nuts - how to overwrite URLs in a vendor tree?

From: hans henderson <hans.svn_at_gmail.com>
Date: 2007-04-30 04:26:51 CEST

Thanks for responding Mark. I've also snipped liberally, but my
original post follows the current one.

On 4/30/07, Mark Phippard <markphip@gmail.com> wrote:
> Subversion copy does not take any more than handful of bytes, as it is
> a virtual copy.

Yes, usually, exactly why I want to use it

> You cannot copy over something, and even if you could, all it would do
> would be to delete + add on one transaction for you. I think there is
> a patch floating around that does just that.
> It sounds like you are looking for copy to somehow merge the contents,
> kind of like a Windows copy does. That is not going to happen.

Not merge in the versioning sense at all, but just overwrite (like a
Windows copy does)
It would be great if that patch were available, maybe as an option
with the cp command, but far be it for me. . .

> I kind of got lost in terms of what you are doing and want to do

<path to>/new-add-on-fileset/xampp (5000 files in 870 directories)
on top of
<path to>/existing-core-fileset/xampp (14000 files in 4000 folders)
adding the new ones and overwriting the existing ones (maybe 20% of
the source fileset)
both paths are URLs

> if you essentially just want to replace what is there, you have to
> just do it in two transactions, a delete followed by a copy. In the
> repository, this will not take any space.

I'd really appreciate it if you could tell me *how to do* the delete
followed by a copy, any way but manually one at a time - not too
practical <g>

I'd be happy to install whatever front-end would help with this.

Or, if this isn't possible (and I'd consider that a bizarre lack on
svn's part myself), then this approach, maybe via some kind of merge?

Check out both trees to my local filesystem, do the copy there and
then somehow commit back to the repository in a way that lets svn know
that the new fileset are already versioned.

Now if that's not possible, then it seems I'm forced to actually store
a duplicate set of files in my repository rather than taking advantage
of svn's ability to prevent this, and that just doesn't seem likely to

Maybe there's an entirely different approach I'm missing here. . .

Thanks again for your help, or of course anyone else who'd like to
chime in here. . .

On 4/30/07, hans henderson <hans.svn@gmail.com> wrote:
> I want to keep a tag of a "virgin" installation tree of an add-on component
> in my repository separate from the "core" tree to which it gets added.
> I also want to keep a branch of the "core+add-on" integrated tree in the
> repository, as that in fact is the basis for the "my stuff" development
> work, and tag that as well, whole point of vendor branches.
> I don't want to have to keep two completely unrelated trees with identical
> files in them, doubling the space taken by the repository completely
> unnecessarily.
> ----------------------
> My latest XAMPP-only "core" tree is here:
> repos/website/vendors/apache-friends/xamppcore/v1.61/xampp
> This currently happens to be exactly the same as:
> repos/website/vendors/current
> I've done an import of the Perl add-on installation tree to here:
> repos/website/vendors/apache-friends/perl-add-on/v5.8.8.819/xampp
> I would like to:
> svn copy
> svn://localhost/vendors/apache-friends/perl-add-on/v5.8.8.819/xampp
> \
> svn://localhost/vendors/current \
> -m "copying the Perl add-on v5.8.8.819 over /current/xampp"
> but that gives me:
> svn: Path 'current/xampp' already exists
> Well *duh!* I know it does; I *want* to overwrite any existing files in the
> core right down the tree with the ones from the new add-on directory, as
> well as adding the new files and directories.
> I reckon there should at least be a --force, but no such option, except for
> messages.
> I rolled my whole repository back to before the import and then imported
> into
> repos/website/vendors/apache-friends/perl-add-on/v5.8.8.819
> (leaving out the offending /xampp), and then did a:
> svn copy
> svn://localhost/vendors/apache-friends/perl-add-on/v5.8.8.819
> \
> svn://localhost/vendors/current/xampp -m "etc"
> but that just *added* a new v5.8.8.819 directory as a sub under
> /current/xampp, and even did the same thing if I changed it to (note the
> trailing slash, should mean "send over the stuff *inside* this directory,
> not the directory itself!")
> svn copy
> svn://localhost/vendors/apache-friends/perl-add-on/v5.8.8.819\
> \
> svn://localhost/vendors/current/xampp \
> (WTF?)
> I did a bit of research in the list archive, and came across this snippet,
> posted by someone basically saying this was reasonable behaviour because
> that's how *nix does it:
> cp path/A path/B --> if path/B doesn't exist, creates path/B
> if path/B does exist, creates path/B/A
> Now where I come from (DOS/Windows) this is nuts, but OK I acknowledge the
> *nix world is superior in every way, I can accept that I'll just have to be
> VERY careful with my copying from now on.
> But for the life of me I can't figure out how to do what I want to do!
> Now out in my local file system, I *could* just copy the unversioned Perl
> add-on tree over my working copy of current and then commit it, but (I
> think) that would be importing 250 MB of files twice into my repository,
> seems to go against the whole point of Subversion.
> Help me please my head hurts. . .

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 30 04:27:11 2007

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