On Jan 15, 2008 8:31 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "Mark Phippard" <markphip_at_gmail.com> writes:
> > In Eclipse, each of my checked out projects lives in the same parent
> > folder locally, but that folder is not itself a WC. Essentially,
> > these WC's are all disconnected. So this is preventing me from
> > copying them all in a single transaction.
> >
> > For commit, I can workaround this limitation with a hack. Before
> > doing the commit, I create a dummy .svn folder in the parent, and then
> > delete it after the commit. This does not work for copy. When I try
> > the same hack (I actually do svn co --depth=empty to create the .svn
> > first) I get a crash. Here is the trace.
> >
> > So my question is simply whether this restriction that all of the
> > folders share a WC parent can be relaxed.
>
> The 1.5 solution to this would be sparse directories: the parent would
> be a wc, but at depth-empty or something, and then you'd include just
> the subdirs (i.e., projects) you want beneath that.
>
> It sounds like you tried that, but via an unusual route: you already
> had the subdirs, and you sort of "inserted" the parent .svn in place
> at depth-empty. Of course it shouldn't crash, but I'm not sure I'd
> expect it to work either (though it would be nice if it did).
>
> Can you make a script that causes this crash using the cmdline client?
It isn't that simple. I cannot use sparse directories for this. The
parent folder in our case is the Eclipse workspace. We cannot really
alter it. Besides, your workspace could have projects from many
different repositories.
In my example, I just used the --depth=empty as a shortcut for making
a syntactically valid .svn folder. In my case the folder I checked
out was not even the parent of these folders.
For commit, the mere presence of a folder named .svn is all you need.
The only exception is if committing a prop change on one of the
top-level folders. In that case, you need to have a format and
entries file that parses correctly. Other than that, the contents do
not seem to matter.
I was hoping that copy could either not recreate this restriction at
all, or at least accept the same hack.
Mark
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-16 02:50:18 CET