[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-users
Subject: Re: Possible bug using svn:external with specific revision for directory that has been renamed
From: Jeffrey Pierson <jpierson () realgreen ! com>
Date: 2013-02-28 20:57:52
Message-ID: CAE4Lr_iVHvt-yxCWHhCHVqfXxcunLjroSZQoPPorcRdQGABLjg () mail ! gmail ! com
[Download RAW message or body]
Excellent, I was hoping I might be doing something wrong. Looks like I have
some mass updates to do in several projects.
Perhaps as a suggestion the documentation for svn:externals should
specifically recommend using peg revisions over the other way of specifying
a specific revision since I can't possibly see why the current behavior of
the -r mechanism to be desirable.
Thanks,
Jeff Pierson
Software Developer
Real Green Systems
On Thu, Feb 28, 2013 at 3:45 PM, C. Michael Pilato <cmpilato@collab.net>wrote:
> On 02/28/2013 03:36 PM, Jeffrey Pierson wrote:
> > I'm seeing the following error when I attempt to update a working copy
> > that has an svn external.
> >
> > svn: warning: W200000: Error handling externals definition for
> > 'MySharedProjectBeforeRename':
> > svn: warning: W160013: File not found: revision 100, path
> > '/trunk/MySharedProjectBeforeRename'
> > svn: E205011: Failure occurred processing one or more externals
> definitions
> >
> > The external is set to a specific revision such as revision r100 and a
> > rename was recently done on that directory as part of revision r101.
> > The external references a project that is located in a separate
> > repository on the same server and has always worked until after the
> > rename. It appears as though when svnserve is resolving the path that
> > it is resolving first from HEAD even though a specific revision was
> > specified. below is an example of what the external definition looks
> > like followed by both the versions of svn client and svnserve that I'm
> > running.
> >
> > -r 100 /shared/trunk/MySharedProjectBeforeRename
> MySharedProjectBeforeRename
>
> You've accurately determined how Subversion is processing your externals
> definition. But it appears you aren't familiar with the general way in
> which Subversion processes URLs/paths and revisions.
>
> I suggest that you first read this:
>
> http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
>
> Then, change your external definition to instead be:
>
> /shared/trunk/MySharedProjectBeforeRename@100MySharedProjectBeforeRename
>
>
> --
> C. Michael Pilato <cmpilato@collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development
>
>
[Attachment #3 (text/html)]
Excellent, I was hoping I might be doing something wrong. Looks like I have some mass \
updates to do in several projects. <br><br>Perhaps as a suggestion the documentation \
for svn:externals should specifically recommend using peg revisions over the other \
way of specifying a specific revision since I can't possibly see why the current \
behavior of the -r mechanism to be desirable.<br>
<br>Thanks,<br clear="all"><div>Jeff Pierson<br>Software Developer<br>Real Green \
Systems<br></div> <br><br><div class="gmail_quote">On Thu, Feb 28, 2013 at 3:45 PM, \
C. Michael Pilato <span dir="ltr"><<a href="mailto:cmpilato@collab.net" \
target="_blank">cmpilato@collab.net</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div class="im">On 02/28/2013 03:36 PM, Jeffrey Pierson wrote:<br>
> I'm seeing the following error when I attempt to update a working copy<br>
> that has an svn external.<br>
><br>
> svn: warning: W200000: Error handling externals definition for<br>
> 'MySharedProjectBeforeRename':<br>
> svn: warning: W160013: File not found: revision 100, path<br>
> '/trunk/MySharedProjectBeforeRename'<br>
> svn: E205011: Failure occurred processing one or more externals definitions<br>
><br>
> The external is set to a specific revision such as revision r100 and a<br>
> rename was recently done on that directory as part of revision r101.<br>
> The external references a project that is located in a separate<br>
> repository on the same server and has always worked until after the<br>
> rename. It appears as though when svnserve is resolving the path that<br>
> it is resolving first from HEAD even though a specific revision was<br>
> specified. below is an example of what the external definition looks<br>
> like followed by both the versions of svn client and svnserve that I'm<br>
> running.<br>
><br>
> -r 100 /shared/trunk/MySharedProjectBeforeRename MySharedProjectBeforeRename<br>
<br>
</div>You've accurately determined how Subversion is processing your \
externals<br> definition. But it appears you aren't familiar with the general \
way in<br> which Subversion processes URLs/paths and revisions.<br>
<br>
I suggest that you first read this:<br>
<br>
<a href="http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html" \
target="_blank">http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html</a><br> \
<br> Then, change your external definition to instead be:<br>
<br>
/shared/trunk/MySharedProjectBeforeRename@100 MySharedProjectBeforeRename<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
C. Michael Pilato <<a \
href="mailto:cmpilato@collab.net">cmpilato@collab.net</a>><br> CollabNet \
<> <a href="http://www.collab.net" target="_blank">www.collab.net</a> \
<> Enterprise Cloud Development<br> <br>
</font></span></blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic