Updating to revision before copy of branch

[Greg Fodor <gr...@parature.com>]

The "svn copy" command's help states that the copy "remembers history." 
After some experimentation (I've been using Subversion for a few months 
now) I think I have a misunderstanding of what this means. Basically, I 
assumed that a branch or a tag of the trunk behaves exactly like a true 
copy (even though internally it is a quick copy.) The log of a branch 
shows all the revisions in the branch, and then additionally all the 
revisions of the original source line of code where the branch was 
copied from. I'm guessing this is what is meant by "including history" 
in a copy.

However, despite the fact I can see all changes in the log back to 
revision 1 (and even surf through the diffs with TortoiseSVN very 
easily) it seems I cannot get svn to apply the history before the point 
of copy. 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."

It seems to me the best behavior for this command would be to back patch 
the branch to revision 100 using the changes made within the branch 
itself (ignoring the trunk) and then further back patch through the 
trunk to revision 50. This way, the branch truly behaves like a copy of 
the trunk at that point in time, including history. This is safe because 
any commit will be made to the latest revision of the branch. It appears 
the information is actually all there, since I can see it in the log, 
but there is no way to apply it. Am I missing something, ie, are there 
ambiguous cases or something that prevent this feature from being 
implemented? Is there a workaround? Essentially my app does "svn 
updates" all the way back through our old code and performs builds to 
generate SQL for migration, but now that we've made release branches, it 
breaks since it can no longer apply simple update commands to get to the 
old versions of the code before that release when working within the branch.

Thanks!



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Updating to revision before copy of branch

[Bob Proulx <bo...@proulx.com>]

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

RE: Updating to revision before copy of branch

[Dale Worley <dw...@pingtel.com>]

> From: Greg Fodor [mailto:greg@parature.com
>
> 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?

Well, that's not what Subversion means by "with history".  It means "this
file is a modified version of some particular earlier revision of some
particular file".  And it's a principle of SCM that past revisions are never
changed.

Dale


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Updating to revision before copy of branch

[Greg Fodor <gr...@parature.com>]

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?

Dale Worley wrote:

>>From: Greg Fodor [mailto:greg@parature.com]
>>
>>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.
>
>Dale
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Updating to revision before copy of branch

[Dale Worley <dw...@pingtel.com>]

> From: Greg Fodor [mailto:greg@parature.com]
>
> 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.

Dale




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org