Greg Fodor wrote:
> Dale Worley wrote:
> > > Ie, if I branch the trunk at revision 100, check out a working
> > > copy of the branch, I am unable to update to any revision before
> > > 100 on that branch from there on out. For example, performing
> > > 'svn update -r 50' on the branch's working copy. Instead, I get
> > > the (uninformative :( ) error message "Cannot replace a
> > > directory from within."
> >
> > That's not very surprising. Because of the location of the file
> > in question in your WC, and the Subversion URL that was checked
> > out to make the WC, you are asking for revision (e.g.) 50 *of a
> > particular file name*. And there was no file of that name in
> > revision 50. In revision 50, there was a file of a different name
> > that is the ancesor of your file name in revision 100, but that's
> > something different.
>
> Hmm.. I see your point. But doesn't this then invalidate the
> clarification that copy is "with history"? If it were with history, then
> essentially the entire repository would behave, post copy, as if the
> branch existed back in revision 50 as well?
Basically the question of implementation is how deep is the fork of
the branch? There are two basic views expressed here.
Implementation A:
Version X ---->----> Version Y
After branch:
Version X ---->----> Version Y
\---> Version Z
This is what subversion currently does. It tracks the copy that
made the branch.
Implementation B:
Version X ---->----> Version Y
After branch:
Version X ---->----> Version Y
Version X ---->----> Version Z
This would be the case if you had forked by doing a complete copy of
the repository.
I think both views of how history is done are valid. But they are
different implementations. You are asking for the second type of
implementation. Subversion currently has a restricted view of
history. This affects copy but more it affects moves and renames
which are really seen as adds and delted. I don't believe this is by
desire of the authors but rather by pragmatic implementation. What is
there is what has had resources to get coded up.
I have seen discussion where this would be better or nicer with more
capability. So perhaps one of these days it will happen. If I recall
correctly this is on the near term roadmap to get worked on and is
also tied to the discussions of how to do improved merging.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 5 23:06:18 2005