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

AW: copying subdirectories in subversion 1.7

From: Markus Schaber <m.schaber_at_3s-software.com>
Date: Tue, 26 Jul 2011 09:11:57 +0200

Hi, Daniel,

Von: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]

> Markus Schaber wrote on Mon, Jul 25, 2011 at 15:57:00 +0200:
> > Hi, Stefan,
> >
> > Von: Stefan Sperling [mailto:stsp_at_elego.de]
> > > > So I'm not only "detaching" subdirectories, but also
> > > > them afterwards.
> > >
> > > Sounds like what you really need is this as-of-yet not implemented
> > > feature:
> > > http://subversion.tigris.org/issues/show_bug.cgi?id=3625
> >
> > Yes, that one would definitely help. :-)
> >
> > Maybe extending "svn diff" and "svn patch" to preserve
> > copy/rename/history information would already be half of that
> > implementation? A "shelve" subdir under .svn/ could then be used to
> > store the diff files.
> >
> That's one solution.
> However, wc.db already has the ability to represent multiple related
> (via op_depth), so another way would be to extend that into storing
> only the post-'svn patch' trees too, and then merging them in the
> way. (which may require repository communication, or storing the pre-
> patch tree locally too...)

I think your suggestion sounds a little bit more complex to start with.

Shelving of patches in .svn/shelve/ can be implemented independently of
the diff/patch extension (with the disadvantage of losing history for
now), and can even be implemented as an external tool / script.

Extending the "diff" and "patch" commands to preserve history (maybe
just by a pointer to url_at_rev) has benefits for other uses (like sending
patches to someone else).

> Perhaps you'd be interested in contributing to the implementation of
> feature?

Yes, I am, but I've only very limited time to work on it while being at

Best regards,

Markus Schaber
Received on 2011-07-26 09:12:46 CEST

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.