[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Updating to revision before copy of branch

From: Bob Proulx <bob_at_proulx.com>
Date: 2005-07-05 22:37:33 CEST

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.


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.