Mark Phippard <MarkP@softlanding.com> writes:
> Here is the original post:
> The thread is not that long. The original patch was for a new subcommand,
> the discussion morphed into that this ought to just be a feature of
> checkout. I believe that some even suggested it ought to be the default
> behavior of checkout. If not, then some sort of switch.
> Basically, the patch would allow svn checkout to "slide a working copy"
> beneath an existing project. Picture all of those KDE developers that had
> CVS working copies on their disks. They could have run an svn co on top
> of that project. Currently, this will abort. With this patch, it would
> create the working copy and leave any existing files alone. svn status
> would then be able to figure out if they were modified.
> I think everyone agreed that this part of the proposal was definitely a
> good idea. Most of the discussion centered around whether it could be
> made even better by using the existing local files to construct the
> working copy (avoiding the new download). Of course it would have to have
> logic to figure out if the local file and the repository file were the
Yup... I remember now. The whole "let's not reimplement rsync"
discussion, since it's enough to just use checksums to decide whether
or not to re-download the entire file or not.
> I think what we are saying now, is let's try to get the original idea
> implemented and then we can talk about making it better later.
> We get a lot of requests in Subclipse that would require a feature like
> this in Subversion in order to implement those requests, so this is
> something I would personally like to see as it would allow me to close a
> number of issues that are open in Subclipse.
Mark, thanks for the summary -- that wasn't so hard to track down, I
now see. Should have just done it myself.
+1 on the idea, either as new option or as new default behavior,
whichever people feel is best. And I wish I had time to help
implement it, instead of just making agreeable noises.
www.collab.net <> CollabNet | Distributed Development On Demand
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Aug 22 23:11:41 2005