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

RE: Question about branching and repository layout

From: Craig L. Ching <cching_at_mqsoftware.com>
Date: 2003-10-10 20:07:47 CEST

> "Craig L. Ching" <cching@mqsoftware.com> writes:
> > Well, I guess that works too, but I think I like my layout better
> > and therefore would probably use the two-step process (mkdir and
> > then copy) instead. I'm sure I'm being naive, but what about the
> > possibility of just creating the necessary structure on the copy to
> > support the layout that the user requests? Import does this, maybe
> > copy could too? And, yes, I know it isn't what cp would do either,
> > just throwing my suggestion out there ;-). Thanks for your time!
> The 'svn cp' command behaves just like the unix 'cp' command. People
> have criticized this, because they think 'svn cp' should give warnings
> about the target already existing. But I don't remember anyone ever
> complaining about the command not auto-creating directories.
Right, I figured that's what you'd say, about it behaving like the unix cp command ;-)

> It sounds like what you really want is '-p' switch to the copy
> command, which would behave like 'mkdir -p' on Unix.
Yeah, exactly, that would be really cool IMO. In validating how Subversion would replace CVS for our development process, I have to determine how it impacts the processes we already have in place (automated builds, packaging our releases, fixing defects, etc.). Being able to create the directory layout the way I've suggested means little impact to our processes, really no impact at all that I can see. I would love a -p switch, definitely.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 10 20:08:50 2003

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

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