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 <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Sep 19 18:54:43 2007