You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/09/08 23:50:04 UTC
Re: svn commit: r26495 - in trunk: subversion/libsvn_client subversion/tests/cmdline www/merge-tracking
On 9/7/07, dlr@tigris.org <dl...@tigris.org> wrote:
> Author: dlr
> Date: Fri Sep 7 12:03:21 2007
> New Revision: 26495
>
> Log:
> Complete issue #2822, handling propagation of mergeinfo for WC -> WC
> copy/move operations.
>
> This commit makes WC -> WC copy/move operations, in conjunction with
> the --use-merge-history option, now require repository access
> (e.g. users may need to be online to use 'svn cp -g wcpath1 wcpath2'
> with a remote repository). Such copy/move operations which do not use
> the --use-merge-history flag won't properly propagate inherited or
> implied mergeinfo to the destination.
As a user, when would I want to use "svn cp -g" and when just standard "svn cp"?
(Is it 'I use always use "svn cp -g" unless I'm on a plane'?)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: WC -> WC copy/move operations and repository access
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> Correct me if I am wrong, but the road you are going down is the
> "defer creating the info" until commit time? The commit can see that
> it is committing a copy and create the mergeinfo at that time?
>
> I think (also trying to remember) the main issue is/was that we made
> this decision to use SVN properties so that people could manually edit
> mergeinfo, and that becomes a problem in this scenario as we do not
> know if that has happened or not. I am not sure how the pre-1.5
> repositories factor into this.
>
> One issue in terms of deferring the creating of mergeinfo is do we
> have the information we need to create the mergeinfo later, at time of
> commit? I think the answer is yes.
I'm not actually talking about deferring anything. I'm saying that we need
*never* to record mergeinfo for copy operations because the item's history
carries the information already. That we store it is merely an optimization
which prevents us from having to query the server about it later, as far as
I can tell. Granted, that optimization might be a very important one that
we'd prefer not to abandon -- I haven't thought that far through the matter.
> Could we get around the property editing problem by inserting a
> property value that tells us to create the info at commit time? Is
> that too ugly?
Yes, and yes. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: WC -> WC copy/move operations and repository access
Posted by Mark Phippard <ma...@gmail.com>.
On 9/19/07, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
> > I hate the idea of svn cp contacting the repository. I think we all
> > do. Where I think I differ from everyone else is that I am not
> > convinced that creating the mergeinfo in a WC to WC copy is vital. At
> > least in terms of a release stopper.
>
> Mark, I know I suggested this on the phone call we had about this topic, but
> I can't recall why it wasn't feasible:
>
> Can our mergeinfo querying logic not just grow smart enough to realize
> that, duh, a copy in an item's history necessarily means that the
> pre-copy revisions are already part of the item's history -- and by
> extension, part of its mergeinfo -- too?
>
> The rebuttal to this was, I think, that we won't know the difference between
> "mergeinfo for the copy was never recorded" and "mergeinfo was explicitly
> removed". But that doesn't make sense to me, and further, seems like we'll
> be starting off the bat with bogus assumptions when using pre-1.5
> repositories. (Surely not every copy made pre-1.5-upgrade carries an
> explicit desire to unrecorded mergeinfo, right?)
>
> It's likely, though, that I'm misremembering here. Can you set the record
> straight?
Heh, I'd rather Dan do that :)
Correct me if I am wrong, but the road you are going down is the
"defer creating the info" until commit time? The commit can see that
it is committing a copy and create the mergeinfo at that time?
I think (also trying to remember) the main issue is/was that we made
this decision to use SVN properties so that people could manually edit
mergeinfo, and that becomes a problem in this scenario as we do not
know if that has happened or not. I am not sure how the pre-1.5
repositories factor into this.
One issue in terms of deferring the creating of mergeinfo is do we
have the information we need to create the mergeinfo later, at time of
commit? I think the answer is yes.
Could we get around the property editing problem by inserting a
property value that tells us to create the info at commit time? Is
that too ugly?
--
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
Re: WC -> WC copy/move operations and repository access
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> I hate the idea of svn cp contacting the repository. I think we all
> do. Where I think I differ from everyone else is that I am not
> convinced that creating the mergeinfo in a WC to WC copy is vital. At
> least in terms of a release stopper.
Mark, I know I suggested this on the phone call we had about this topic, but
I can't recall why it wasn't feasible:
Can our mergeinfo querying logic not just grow smart enough to realize
that, duh, a copy in an item's history necessarily means that the
pre-copy revisions are already part of the item's history -- and by
extension, part of its mergeinfo -- too?
The rebuttal to this was, I think, that we won't know the difference between
"mergeinfo for the copy was never recorded" and "mergeinfo was explicitly
removed". But that doesn't make sense to me, and further, seems like we'll
be starting off the bat with bogus assumptions when using pre-1.5
repositories. (Surely not every copy made pre-1.5-upgrade carries an
explicit desire to unrecorded mergeinfo, right?)
It's likely, though, that I'm misremembering here. Can you set the record
straight?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: WC -> WC copy/move operations and repository access
Posted by Mark Phippard <ma...@gmail.com>.
On 9/19/07, Karl Fogel <kf...@red-bean.com> wrote:
> Daniel Rall <dl...@collab.net> writes:
> > I would prefer to completely avoid needing to immediately contact the
> > repository. I've discussed two possible strategies for doing so (with
> > at least cmpilato, pburba, markphip, kfogel, and glasser):
> >
> > 1) Keep track of local copy/move operations in a manner which queues
> > up mergeinfo modifications until the repository is subsequently
> > contacted (e.g. for an update, merge, or switch). Maintain this "soft
> > mergeinfo" state a WC-specific property which is examined at the
> > beginning of each repository contact, and tweaks mergeinfo accordingly.
> >
> > 2) Use an "inherited properties" implementation to maintain a local
> > cache of property values inherited from above the root of your WC
> > tree. This doesn't alleviate the need to contact the repository to
> > include a moved/copied path's implied mergeinfo (the contiguous set of
> > revisions at which an object has been at its current path).
>
> I think (2) is feasible now -- we already have an idea how to
> implement it, and it would be generically valuable for other features,
> not just mergeinfo inheritance. I've been trying to finish up
> sparse-directories as fast as I can (principally issues #2847 and
> #2844, which are going like gangbusters) in order to work on that.
>
> However, if inherited properties wouldn't alleviate the problem at
> hand, then they should take back burner. IMHO, the fact that 'cp' has
> effectively become a non-local operation is Really Really Bad: users
> are going to freak out about it. We positively *have* to fix it, and
> if solution (1) is the only way, then let's get on it.
>
> Not that I ever want to discourage on-list discussion, but Dan, next
> week when Mark is in town let's make sure this is on the agenda for
> when we meet up.
Let me just restate my thoughts as I do not think anyone has addressed
them directly.
I do not think either of these options are feasible, in terms of
trying to branch on October 12th. I have some question as to whether
we could even branch this year as I see inheritable properties as an
issue that will have its own edge cases and feature creep. For
example, even if we do not expose them in the UI or use the feature to
address other issues (like log templates) we will at least have to
consider how 1.6 will do those things to make sure we are approaching
it right.
So schedule and getting a 1.5 release done is one issue. I wanted to
get the svn copy -g solution in place in case we decide in favor of
getting a release done.
I hate the idea of svn cp contacting the repository. I think we all
do. Where I think I differ from everyone else is that I am not
convinced that creating the mergeinfo in a WC to WC copy is vital. At
least in terms of a release stopper.
We know if you have a relevant subset of your repository checked out
and you are creating branches using WC to WC that it is relevant. The
-g option was added to address this. I do not see this as a problem
for this scenario.
In day to day usage of the cp and mv commands, I fail to see anything
but edge case scenarios where the mergeinfo matters.
I do not want to ship a less than perfect solution any more than
anyone else, but we can spend forever (and already have) dealing with
edge cases. Meanwhile, there are bigger flaws like cyclic merges and
tree conflicts that we are already deferring. I say defer the edge
cases, ship the release and get started on 1.6.
I reserve the right to be convinced that there are fairly common cases
where this info is essential and the -g option is a burden on the
user.
--
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
Re: WC -> WC copy/move operations and repository access
Posted by Karl Fogel <kf...@red-bean.com>.
Daniel Rall <dl...@collab.net> writes:
> I would prefer to completely avoid needing to immediately contact the
> repository. I've discussed two possible strategies for doing so (with
> at least cmpilato, pburba, markphip, kfogel, and glasser):
>
> 1) Keep track of local copy/move operations in a manner which queues
> up mergeinfo modifications until the repository is subsequently
> contacted (e.g. for an update, merge, or switch). Maintain this "soft
> mergeinfo" state a WC-specific property which is examined at the
> beginning of each repository contact, and tweaks mergeinfo accordingly.
>
> 2) Use an "inherited properties" implementation to maintain a local
> cache of property values inherited from above the root of your WC
> tree. This doesn't alleviate the need to contact the repository to
> include a moved/copied path's implied mergeinfo (the contiguous set of
> revisions at which an object has been at its current path).
I think (2) is feasible now -- we already have an idea how to
implement it, and it would be generically valuable for other features,
not just mergeinfo inheritance. I've been trying to finish up
sparse-directories as fast as I can (principally issues #2847 and
#2844, which are going like gangbusters) in order to work on that.
However, if inherited properties wouldn't alleviate the problem at
hand, then they should take back burner. IMHO, the fact that 'cp' has
effectively become a non-local operation is Really Really Bad: users
are going to freak out about it. We positively *have* to fix it, and
if solution (1) is the only way, then let's get on it.
Not that I ever want to discourage on-list discussion, but Dan, next
week when Mark is in town let's make sure this is on the agenda for
when we meet up.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
WC -> WC copy/move operations and repository access
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 10 Sep 2007, Mark Phippard wrote:
> On 9/10/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> > Daniel Rall <dl...@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.
...
> 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?
Yes, this will be the most common scenario. Typical exceptions will
include paths below the level of the branch which have had their
mergeinfo modified (potentially due to other copy/move operations).
Karl wrote:
> FWIW, I think contacting the repository should be the default too.
> Yes, it stinks, but it doesn't stink as much as mergeinfo ever not
> working right by default.
>
> I'd like to find a way to avoid the need to contact the repository,
> via inheritable mergeinfo prop data. But that may not happen in time
> for 1.5.
I would prefer to completely avoid needing to immediately contact the
repository. I've discussed two possible strategies for doing so (with
at least cmpilato, pburba, markphip, kfogel, and glasser):
1) Keep track of local copy/move operations in a manner which queues
up mergeinfo modifications until the repository is subsequently
contacted (e.g. for an update, merge, or switch). Maintain this "soft
mergeinfo" state a WC-specific property which is examined at the
beginning of each repository contact, and tweaks mergeinfo accordingly.
2) Use an "inherited properties" implementation to maintain a local
cache of property values inherited from above the root of your WC
tree. This doesn't alleviate the need to contact the repository to
include a moved/copied path's implied mergeinfo (the contiguous set of
revisions at which an object has been at its current path).
Re: svn commit: r26495 - in trunk: subversion/libsvn_client subversion/tests/cmdline www/merge-tracking
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> 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.
FWIW, I think contacting the repository should be the default too.
Yes, it stinks, but it doesn't stink as much as mergeinfo ever not
working right by default.
I'd like to find a way to avoid the need to contact the repository,
via inheritable mergeinfo prop data. But that may not happen in time
for 1.5.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r26495 - in trunk: subversion/libsvn_client subversion/tests/cmdline www/merge-tracking
Posted by Mark Phippard <ma...@gmail.com>.
On 9/10/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> Daniel Rall <dl...@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
Re: svn commit: r26495 - in trunk: subversion/libsvn_client subversion/tests/cmdline www/merge-tracking
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Daniel Rall <dl...@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.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r26495 - in trunk: subversion/libsvn_client subversion/tests/cmdline www/merge-tracking
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Sep 8, 2007, at 4:50 PM, David Glasser wrote:
> On 9/7/07, dlr@tigris.org <dl...@tigris.org> wrote:
>> Author: dlr
>> Date: Fri Sep 7 12:03:21 2007
>> New Revision: 26495
>>
>> Log:
>> Complete issue #2822, handling propagation of mergeinfo for WC -> WC
>> copy/move operations.
>>
>> This commit makes WC -> WC copy/move operations, in conjunction with
>> the --use-merge-history option, now require repository access
>> (e.g. users may need to be online to use 'svn cp -g wcpath1 wcpath2'
>> with a remote repository). Such copy/move operations which do not
>> use
>> the --use-merge-history flag won't properly propagate inherited or
>> implied mergeinfo to the destination.
>
> As a user, when would I want to use "svn cp -g" and when just
> standard "svn cp"?
>
> (Is it 'I use always use "svn cp -g" unless I'm on a plane'?)
Yes, you'll always want 'svn cp -g'.
I'd prefer to avoid having to contact the repository at all, but the
client simply doesn't have sufficient information. We've discussed
the possibility of delaying contacting the repository until a
subsequent 'svn merge' or 'svn update' or 'svn commit' or some such
occurs, but work on such a solution hasn't been scoped.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org