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

Re: When to merge sparse-directories branch to trunk?

From: Michael Brouwer <mb.7766_at_gmail.com>
Date: 2007-01-24 19:07:42 CET

Just out of curiosity have you looked at how svk solves this?

With svk the -N option is sticky, meaning update won't grab files or folders
that are missing, instead it marks them with a '!'. You have to svk revert
-R to actually get a directory back. (or without the -R for files). This
makes spare checkouts work quite well, and I believe svn could be made to
work the same way without the need for as much new code as is currently in
this branch.

Michael

On 1/24/07, Blair Zajac <blair@orcaware.com> wrote:
>
> Karl Fogel wrote:
> > On 1/22/07, Daniel Rall <dlr@collab.net> wrote:
> >> After briefly scoping the changes out, it looks like the current state
> >> of affairs on the sparse-directories is merge-able with the
> >> merge-tracking branch in about half a day's work. I'd rather see this
> >> happen now, rather than it diverge any futher on a separate branch.
> >> +1 to merge sparse-directories to trunk ASAP.
> >
> > Thanks for looking over this. I'll try to merge as soon as I can. I
> > don't want to do it until some of the more serious issues mentioned
> > in README.branch are taken care of (we're still trying to run a
> > quality shop here, after all), but will try to arrange my time so as
> > to optimize for a sooner merge.
>
> +1.
>
> As somebody who works on a team that would heavily use this feature, I too
> would
> like to see a sooner merge.
>
> Regards,
> Blair
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Wed Jan 24 19:08:04 2007

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.