On Tue, Feb 26, 2008 at 4:35 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Feb 26, 2008 at 6:36 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > My kneejerk reaction is that I'm hoping for future Subversion working
> > copies to be more discrete than current ones, not less so, and my
> > design goals for a WC rewrite would be to explicitly disallow
> > multiple-WC operations. So I'm not inclined to focus too much on
> > making multi-WC operations work better... But that may just be me.
>
> I will go ballistic if we disallow this. I absolutely need multi-WC
> operations in Subclipse. One of SVN's number one features is atomic
> operations, so imagine how pissed users are when their commits from
> Eclipse span multiple transactions. I at least need this for all
> write operations (commit, copy, move).
>
> I currently hack around this limitation at run time by creating a .svn
> folder in the parent, but I would like to see it just work in
> Subversion core API. The new support in copy/move for multiple
> sources has the same problem except the hack does not work.
We'll see how things work out once we're actually at the point of
designing a new wc library. It would seem to me that we would lose a
lot of the benefits of monolithic working copies if you still have to
synchronize your metadata between a bunch of separate working copies.
Perhaps having perforce-style client specs would allow us to have
working copies that look (on disk) like your Eclipse checkouts but are
still one big working copy. But this is a discussion for later,
perhaps.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-27 01:43:24 CET