On 9/10/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> Daniel Rall <dlr@finemaltcoding.com> writes:
>
> > Yes, you'll always want 'svn cp -g'.
>
> Sorry if I missed something, but I still think contacting the
> repository should be the default, with a separate option to skip
> the contact. There's the abstract argument that if an option is
> nearly always required, you've chosen the wrong default. But we
> have a more compelling argument.
>
> Users have been running svn cp for years, without -g, naturally.
> They hear 1.5 has merge tracking, but aren't going to read the
> release notes in enough detail to note that they have to use cp
> -g all the time. Even those who do are going to have trouble
> adapting their habits. Then, later on, they'll find out that
> merge tracking "isn't working". I think that's bad.
>
> Subversion strives to be WAN-friendly, but does not strive to be
> distributed, i.e. network-independent. We should optimize for
> the common case. When someone runs svn cp WC WC on a plane,
> they'll eventually get an error message about name lookup,
> connection refused, or whatever, and a warning that we're copying
> without mergeinfo.
I pushed Dan in the current direction (although it was not hard). The
feeling is that the current need to contact the repository stinks,
with our without the -g. It is just too ugly to be the default. We
decided to do it using -g to make sure that "working code" is in
place. But the idea was that what this particularly feature really
needs is a redesign where it does not need to contact the repository
(defer the mergeinfo or just not need it). Dan and Karl discussed
some ideas. They think implementing it is doable, but right now it is
just an unknown amount of effort. So anyway, the feeling was that
making this behavior the default was just not a good idea.
I am still not convinced that for a lot of "routine" copies that the
mergeinfo is even needed. Obviously if you are creating a branch/tag
locally it would be, but it seems like that could be managed.
Updating scripts etc. to do it would not be hard.
I have not decided what I am going to do in Subclipse. It'd be
difficult to prompt the user every time they did a refactoring and I
cannot imagine contacting the repository by default for each of these
operations. Obviously how I handle it in Subclipse has nothing to do
with the command line default either way, just pointing out my own
dilemmas here.
Suppose I have a common scenario where I have a feature branch. The
root of the branch had mergeinfo set when I created it. During
development, I move some code around. I do not understand what
mergeinfo needs to be written and why. The mergeinfo is up on the
parent and nothing has really changed. Isn't this by far the most
common WC to WC copy/move scenario?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 11 01:23:32 2007