You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Phillip Susi <ps...@cfl.rr.com> on 2007/02/09 21:44:24 UTC
Branch causes missing revs and errors merging
I have noticed that when I do some work in my working copy and decide to
commit it as a branch instead, it causes some strange problems when I go
back to try and merge. Specifically when I choose the range of
revisions in the branch to merge back into the trunk in tsvn, it gets an
error saying that it can not find that path in rev xxx, where rev xxx is
the one prior to the first rev in the branch I selected.
I tried merging or even simply listing from the command line as well,
and this also fails. It looks like what happened is that when I forked
the branch, it created a hole in the revision history. If the trunk is
initially at rev 5, and by the time you choose to commit your changes as
a branch, others have modified the trunk and it is now at rev 9, then
when you commit your wc as a branch in rev 10, the history of /branch
does not exist in revs 6-9. If you try to svn ls /branch -r9 it fails
saying that location could not be found in that revision. Same goes for
revisions 6, 7, and 8, but if you try revision 5, it works properly.
This causes problems when merging because you try to merge using r9 as
the start revision because r10 is the first commit in that branch
containing modifications, you want to track the changes including that
initial commit. When you manually choose r9 or tsvn does ( since it is
1 before the first commit in that branch ), you get this error.
Is this a bug and is there any way to avoid it, other than manually
tracking back to the revision before the hole?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Jeff Smith <js...@robotronics.com>.
On Friday 16 February 2007 09:01, Phillip Susi wrote:
> Forget about merging. The issue is that a file exists in rev 1,
> and in rev 4, but magically does not exist in 2 and 3. It does not
> make sense for a file to be created, then no longer exist for a
> while, then pop back up again. In any other case if the log shows
> that a file was created in rev 1 and modified in rev 4, then it
> existed in 2 and 3 as well.
I think the question is whether you want to use Subversion, or not. It
is powerful if you learn how. Useless if you insist on creating your
own explanation of what it's doing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/19/07, Phillip Susi wrote:
> Frodak Baksik wrote:
> > Thinking about this more, you almost never want the behavior you describe.
> >
> > For instance, lets say you have file foo in r10, delete it in r11, and
> > then:
> > svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
>
> This command will fail actually; you have to use a peg revision since
> the name /repo/trunk/foo does not exist in HEAD.
Actually it won't because as according to the documentation the copy
command does not use peg revisions. Here, I'll quote it for you:
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/20/07, Phillip Susi wrote:
> Frodak Baksik wrote:
> > Actually it won't because as according to the documentation the copy
> > command does not use peg revisions. Here, I'll quote it for you:
> >
> > From the book:
> > A second, more targeted strategy is not to use svn merge at all, but
> > rather the svn copy command.
> > Simply copy the exact revision and path "coordinate pair" from the
> > repository to your
> > working copy:
> > $ svn copy --revision 807 \
> > http://svn.example.com/repos/calc/trunk/real.c ./real.c
> > $ svn status
> > A + real.c
>
> Oh my, that is really messed up. The copy command then, uses the common
> parameter in a manner that is inconsistent with the way that common
> parameter is used with all other svn commands. The other commands
> resolve the name in the peg revision, then track the history back to the
> revision specified in -r. Copy interprets -r AS the peg revision. This
> inconsistency is poor behavior.
Wouldn't it have been nice to verify your statements, instead of
assuming I was just wrong.
> > This suggests to me if that you can't locate the item via e.g. ls
> > file@rev then it just doesn't exist in that revision. The behavior
> > you are implying is buggy seems to be an extension of this metaphor.
> >
> > I'll just end it with I don't agree with your interpretation of object
> > existence in regards to subversion even though your interpretation may
> > have been appropriate for other CM tools that I've used.
>
> If you accept that it is ok philosophically to have a hole in a timeline
> where a thing did exist, then doesn't, then does again, without having
> undergone creation or destruction in between, that is your choice I
> suppose, but it does break assumptions made by other parts of subversion
> ( the -rPREV I mentioned ) so it appears to not be intentional.
>
In the operations I've demonstrated I believe the object does get
destroyed and recreated, was I not clear enough? For example:
deleting a file in a directory destroys the file in that revision. I
think that this is true, I get the impression from your previous
statements, you don't agree. But, please don't make stuff up, its
kind of aggravating.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 20, 2007, at 10:07, Phillip Susi wrote:
> Frodak Baksik wrote:
>
>> Actually it won't because as according to the documentation the copy
>> command does not use peg revisions. Here, I'll quote it for you:
>> From the book:
>> A second, more targeted strategy is not to use svn merge at all, but
>> rather the svn copy command.
>> Simply copy the exact revision and path "coordinate pair" from the
>> repository to your
>> working copy:
>> $ svn copy --revision 807 \
>> http://svn.example.com/repos/calc/trunk/real.c ./real.c
>> $ svn status
>> A + real.c
>
> Oh my, that is really messed up. The copy command then, uses the
> common parameter in a manner that is inconsistent with the way that
> common parameter is used with all other svn commands. The other
> commands resolve the name in the peg revision, then track the
> history back to the revision specified in -r. Copy interprets -r
> AS the peg revision. This inconsistency is poor behavior.
And I believe this inconsistency has already been fixed for
Subversion 1.5.0:
http://subversion.tigris.org/issues/show_bug.cgi?id=2546
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Frodak Baksik wrote:
> Actually it won't because as according to the documentation the copy
> command does not use peg revisions. Here, I'll quote it for you:
>
> From the book:
> A second, more targeted strategy is not to use svn merge at all, but
> rather the svn copy command.
> Simply copy the exact revision and path "coordinate pair" from the
> repository to your
> working copy:
> $ svn copy --revision 807 \
> http://svn.example.com/repos/calc/trunk/real.c ./real.c
> $ svn status
> A + real.c
Oh my, that is really messed up. The copy command then, uses the common
parameter in a manner that is inconsistent with the way that common
parameter is used with all other svn commands. The other commands
resolve the name in the peg revision, then track the history back to the
revision specified in -r. Copy interprets -r AS the peg revision. This
inconsistency is poor behavior.
> This suggests to me if that you can't locate the item via e.g. ls
> file@rev then it just doesn't exist in that revision. The behavior
> you are implying is buggy seems to be an extension of this metaphor.
>
> I'll just end it with I don't agree with your interpretation of object
> existence in regards to subversion even though your interpretation may
> have been appropriate for other CM tools that I've used.
If you accept that it is ok philosophically to have a hole in a timeline
where a thing did exist, then doesn't, then does again, without having
undergone creation or destruction in between, that is your choice I
suppose, but it does break assumptions made by other parts of subversion
( the -rPREV I mentioned ) so it appears to not be intentional.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/19/07, Phillip Susi wrote:
> Frodak Baksik wrote:
> > Thinking about this more, you almost never want the behavior you describe.
> >
> > For instance, lets say you have file foo in r10, delete it in r11, and
> > then:
> > svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
>
> This command will fail actually; you have to use a peg revision since
> the name /repo/trunk/foo does not exist in HEAD.
Actually it won't because as according to the documentation the copy
command does not use peg revisions. Here, I'll quote it for you:
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Frodak Baksik wrote:
> Thinking about this more, you almost never want the behavior you describe.
>
> For instance, lets say you have file foo in r10, delete it in r11, and
> then:
> svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
This command will fail actually; you have to use a peg revision since
the name /repo/trunk/foo does not exist in HEAD.
> When you perform the ls, cp, diff, etc commands, for versions 11, 12,
> 13 you want it to say it does not exist in those versions.
No, you don't. The file did exist in those revisions, it simply had no
name in any directory in that revision. Once you resolve the name ( in
HEAD or any other specified peg revision ), you are supposed to be able
to retrieve the state of that file in any rev as far back as the log
shows the file was created in.
> Then in r15 you delete the file again and then in r17 you restore
> version 10 again:
> svn cp -r10 file:///repo/trunk/foo file:///repo/trunk
>
> What should the command log -r14 file:///repo/trunk/foo return?
It will show that the file was copied in rev 17, from rev 10, and track
the history back from there. If you wanted to access the file that was
restored, modified, and deleted, then you have to refer to that file
with a peg revision. This is how it works now and I am perfectly fine
with that.
> It should return that it could not find the object in r14, because r14
> object is from a different line of history then the HEAD object.
No. When you don't specify a peg revision, the name is resolved in
HEAD. The object to which that name refers DID exist in r14, since it
was created prior to that. While this is not the same object that held
that name in r14, it did exist as of r14.
> As of now, SVN seems to be fairly consistent, an object does not exist
> between the version it was copied from and the version it was copied
> to.
Yes, it consistently leaves a hole in the history of the file when it is
copied. This hole breaks a number of expectations of both users and
tools. For instance, -rPREV assumes that it can find HEAD-1, so fails
in this case. If holes in the revision history were allowed, then
resolving PREV would have to fetch the log and find the last revision it
was changed in, but this is not the case. Instead it seems to be held
as an invariant that access to a file in revisions in which it was not
modified should work.
> I.E
> $ svn log file_1.txt -v
> ------------------------------------------------------------------------
> r18 | fbaksik | 2007-02-17 08:58:02 -0500 (Sat, 17 Feb 2007) | 1 line
> Changed paths:
> A /trunk/main/file_1.txt (from /trunk/main/file_1.txt:13)
>
> Restore file again.
>
> Any reference, of r14 to r17 (inclusive), will return an object not
> found type of error.
Does, but should not. Only @14 to @17 should do this because the NAME
did not exist in those revisions, but the FILE ( which is found in the
HEAD revision ) DID exist in those revisions.
> What you are asking for is to break this simple rule and say, if the
> object I copy from is a different path than what I copy to, then say
> the object does exist! But even this is not a hard and fast rule
> because if you folder renames the same time you do add or deletes,
> it'll look like you are copying from a different path when you're not.
No, it has nothing to do with whether or not the paths are different.
The problem is that an add-with-history operation leaves a hole in the
file history between the rev the history is copied from, and the rev
that the copy is performed in. This hole needs to be bridged at the
time of the copy so that the file's state can be accessed in those
revisions, as it existed in the last revision it was modified in prior
to the rev it is copied from.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/16/07, Phillip Susi <ps...@cfl.rr.com> wrote:
> Jeff Smith wrote:
> > Phillip,
> >
> > It makes sense to me that the merge should be starting from the
> > "copy-from" rev and not from the "copy-to" rev minus one. (it means
> > Frodak makes sense)
> >
> > I was confused when learning subversion because each rev is global to
> > the entire tree. What I learned, which might help visualize this
> > merge issue, is that the changes in a diff come from a combination of
> > the range (i.e. -r1:4) *and* the path given.
>
> Forget about merging. The issue is that a file exists in rev 1, and in
> rev 4, but magically does not exist in 2 and 3. It does not make sense
> for a file to be created, then no longer exist for a while, then pop
> back up again. In any other case if the log shows that a file was
> created in rev 1 and modified in rev 4, then it existed in 2 and 3 as
> well.
>
> > What I mean is that I would have been afraid that rev 2 & 3 would have
> > somehow messed up your merge if included in the range, but it does
> > not because those revisions had nothing to do with your branch.
> >
> > Since you were looking the revisions specifically related to the
> > combination -r3 and your branch path {i.e. svn log
> > -r3:4 /repo/branch}, naturally those were not found because that path
> > was not in rev 3.
>
> The PATH is found in the HEAD revision because a peg revision was not
> used to change that. Once the path has been resolved, the file's
> history shows that it was created in rev 1, yet an attempt to access
> it's state in rev 2 fails. There is a big difference between svn ls
> /repo/branch@3 and svn ls -r3 /repo/branch. The former fails for the
> reason you mention, the latter should not. Notice how -r1 works even
> though branch did not exist with that name in r1 either, but it DID exist.
Thinking about this more, you almost never want the behavior you describe.
For instance, lets say you have file foo in r10, delete it in r11, and then:
svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
When you perform the ls, cp, diff, etc commands, for versions 11, 12,
13 you want it to say it does not exist in those versions.
Then in r15 you delete the file again and then in r17 you restore
version 10 again:
svn cp -r10 file:///repo/trunk/foo file:///repo/trunk
What should the command log -r14 file:///repo/trunk/foo return?
It should return that it could not find the object in r14, because r14
object is from a different line of history then the HEAD object.
As of now, SVN seems to be fairly consistent, an object does not exist
between the version it was copied from and the version it was copied
to.
I.E
$ svn log file_1.txt -v
------------------------------------------------------------------------
r18 | fbaksik | 2007-02-17 08:58:02 -0500 (Sat, 17 Feb 2007) | 1 line
Changed paths:
A /trunk/main/file_1.txt (from /trunk/main/file_1.txt:13)
Restore file again.
Any reference, of r14 to r17 (inclusive), will return an object not
found type of error.
What you are asking for is to break this simple rule and say, if the
object I copy from is a different path than what I copy to, then say
the object does exist! But even this is not a hard and fast rule
because if you folder renames the same time you do add or deletes,
it'll look like you are copying from a different path when you're not.
Personally, I vote keep it simple.
:-)
Frodak
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Jeff Smith wrote:
> Phillip,
>
> It makes sense to me that the merge should be starting from the
> "copy-from" rev and not from the "copy-to" rev minus one. (it means
> Frodak makes sense)
>
> I was confused when learning subversion because each rev is global to
> the entire tree. What I learned, which might help visualize this
> merge issue, is that the changes in a diff come from a combination of
> the range (i.e. -r1:4) *and* the path given.
Forget about merging. The issue is that a file exists in rev 1, and in
rev 4, but magically does not exist in 2 and 3. It does not make sense
for a file to be created, then no longer exist for a while, then pop
back up again. In any other case if the log shows that a file was
created in rev 1 and modified in rev 4, then it existed in 2 and 3 as
well.
> What I mean is that I would have been afraid that rev 2 & 3 would have
> somehow messed up your merge if included in the range, but it does
> not because those revisions had nothing to do with your branch.
>
> Since you were looking the revisions specifically related to the
> combination -r3 and your branch path {i.e. svn log
> -r3:4 /repo/branch}, naturally those were not found because that path
> was not in rev 3.
The PATH is found in the HEAD revision because a peg revision was not
used to change that. Once the path has been resolved, the file's
history shows that it was created in rev 1, yet an attempt to access
it's state in rev 2 fails. There is a big difference between svn ls
/repo/branch@3 and svn ls -r3 /repo/branch. The former fails for the
reason you mention, the latter should not. Notice how -r1 works even
though branch did not exist with that name in r1 either, but it DID exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Jeff Smith <js...@robotronics.com>.
On Thursday 15 February 2007 12:16, Phillip Susi wrote:
> > But that is immaterial to the discussion. We are both in
> > agreement that the contents of branch exist in revision 1 and
> > that branch exists in revision 4. We disagree about revs 2 and
> > 3.
>
> Yes.
>
> > I do understand the difference and I understand what you are
> > trying to say. Personally I don't think it is an issue, sorry.
>
> Do you disagree that an object should exist at all points in time
> between creation and destruction? Subversion maintains a timeline
> of the history of a file. There should not be holes in a timeline.
Phillip,
It makes sense to me that the merge should be starting from the
"copy-from" rev and not from the "copy-to" rev minus one. (it means
Frodak makes sense)
I was confused when learning subversion because each rev is global to
the entire tree. What I learned, which might help visualize this
merge issue, is that the changes in a diff come from a combination of
the range (i.e. -r1:4) *and* the path given.
What I mean is that I would have been afraid that rev 2 & 3 would have
somehow messed up your merge if included in the range, but it does
not because those revisions had nothing to do with your branch.
Since you were looking the revisions specifically related to the
combination -r3 and your branch path {i.e. svn log
-r3:4 /repo/branch}, naturally those were not found because that path
was not in rev 3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Jeff Smith <js...@robotronics.com>.
On Thursday 15 February 2007 15:15, Phillip Susi wrote:
> Since a move in svn is just a copy+delete, renaming should have the
> same effect. I just checked this by renaming the trunk to branch
> instead of copying and it causes the same problem.
>
> It looks like this issue is not specific to branch/merge, but
> rather is a problem any time there is an add with history, and that
> add is committed in a revision other than the one immediately
> following the revision that the history is taken from. This leaves
> a hole with no history at all in between those two points. If
> there is history before, and after, then there should be something
> there during that interval showing that nothing was changed.
Phillip,
It looks like the problem is not specific to either of those, but to
you, misunderstanding what subversion needs to do.
from your example try
svn log -v repo/branch
and see if the "-v" helps you see in what way "repo/branch" exists in
rev1. I think you have something else to work out in your mind... why
the changes you want to merge would be -r1:4 and not -r3:4 if that
was the situation (I lose track).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Frodak Baksik wrote:
>> Do you disagree that an object should exist at all points in time
>> between creation and destruction? Subversion maintains a timeline of
>> the history of a file. There should not be holes in a timeline.
>
> No, I don't disagree with that. But we apparently have different
> views on when an object is created.
Initially I based on my view on when it was created on the output of svn
log, which shows the history back to r1. I assumed from this history
that the object did exist in r1.
> I see a copy as creating a new object (as opposed to a move that,
> well, moves an already existing object), perhaps that is the wrong
> view to have with Subversion. Perhaps someone on the dev team could
> shed some insight?
Since a move in svn is just a copy+delete, renaming should have the same
effect. I just checked this by renaming the trunk to branch instead of
copying and it causes the same problem.
It looks like this issue is not specific to branch/merge, but rather is
a problem any time there is an add with history, and that add is
committed in a revision other than the one immediately following the
revision that the history is taken from. This leaves a hole with no
history at all in between those two points. If there is history before,
and after, then there should be something there during that interval
showing that nothing was changed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/15/07, Phillip Susi <ps...@cfl.rr.com> wrote:
> Frodak Baksik wrote:
> > No, I actually did try it. Please re-read your directions on setting
> > up the repository.
> > Your example starts with a checkout the root directory of the repos,
> > you create trunk and some files within truck, and then copy the WC to
> > /branch. That is what I did. Therefore you will get trunk as a
> > subdirectory of branch.
>
> Sorry, I made a typeo. That should have been copy trunk to branch, not
> the root.
>
> > But that is immaterial to the discussion. We are both in agreement
> > that the contents of branch exist in revision 1 and that branch exists
> > in revision 4. We disagree about revs 2 and 3.
>
> Yes.
>
> > I do understand the difference and I understand what you are trying to
> > say. Personally I don't think it is an issue, sorry.
>
> Do you disagree that an object should exist at all points in time
> between creation and destruction? Subversion maintains a timeline of
> the history of a file. There should not be holes in a timeline.
No, I don't disagree with that. But we apparently have different
views on when an object is created.
I see a copy as creating a new object (as opposed to a move that,
well, moves an already existing object), perhaps that is the wrong
view to have with Subversion. Perhaps someone on the dev team could
shed some insight?
> > Regardless of all that, please see my other post on how to perform the
> > merge. While you may think that it is sub-optimal it does work.
>
> It does work, but it is a manual workaround to a bug and automated tools
> like the merge feature of tortoisesvn either can't automate such a
> workaround or it would be exceedingly difficult. Better to fix the bug.
> Things also get especially complex when you have a branch that is a
> mix of copies from different versions.
Then perhaps the other tools should follow the best practices of
branching to avoid such issues? Perhaps that's why it hasn't really
been discussed before. Anyways until the issues get fixed (and the
other open bugs), I would just avoid it.
:-)
Frodak
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Frodak Baksik wrote:
> No, I actually did try it. Please re-read your directions on setting
> up the repository.
> Your example starts with a checkout the root directory of the repos,
> you create trunk and some files within truck, and then copy the WC to
> /branch. That is what I did. Therefore you will get trunk as a
> subdirectory of branch.
Sorry, I made a typeo. That should have been copy trunk to branch, not
the root.
> But that is immaterial to the discussion. We are both in agreement
> that the contents of branch exist in revision 1 and that branch exists
> in revision 4. We disagree about revs 2 and 3.
Yes.
> I do understand the difference and I understand what you are trying to
> say. Personally I don't think it is an issue, sorry.
Do you disagree that an object should exist at all points in time
between creation and destruction? Subversion maintains a timeline of
the history of a file. There should not be holes in a timeline.
> Regardless of all that, please see my other post on how to perform the
> merge. While you may think that it is sub-optimal it does work.
It does work, but it is a manual workaround to a bug and automated tools
like the merge feature of tortoisesvn either can't automate such a
workaround or it would be exceedingly difficult. Better to fix the bug.
Things also get especially complex when you have a branch that is a
mix of copies from different versions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/15/07, Phillip Susi wrote:
> Please don't trim the Cc list.
>
> Frodak Baksik wrote:
> > How are you using diff?
>
> svn diff -r3 branch/foo
>
> > I mention it because I don't know how you determined that branch
> > exists in revision 1.
>
> If you do NOT use --stop-on-copy then the log of branch shows that it
> did exist back in rev 1, under the trunk.
>
> > $ svn ls file:///svn/repo/branch@1
> > svn: URL 'file:///svn/repo/branch' non-existent in that revision
>
> You used a peg revision, which is different. The name branch did not
> exist in rev 1. When you use a -r instead of a peg revision, the name
> gets resolved in HEAD, which works because the name branch exists there,
> but you specify that the state of the file should be tracked back to how
> it was in a previous rev. This is supposed to work for any and all revs
> in the file history back to the point where it was originally created.
>
> > $ svn ls file:///svn/repo/branch@2
> > svn: URL 'file:///svn/repo/branch' non-existent in that revision
> >
> > $ svn ls file:///svn/repo/branch@3
> > svn: URL 'file:///svn/repo/branch' non-existent in that revision
> >
> > $ svn ls file:///svn/repo/branch@4
> > trunk/
> >
> > To me this indicates that file:///svn/repo/branch only exists in
> > revision 4.
>
> The NAME only exists as of rev 4, but the file itself existed since rev
> one, under the name /trunk. This is confirmed by svn log, and svn ls or
> diff with -r1, which works.
>
> > $ svn ls -r1 file:///svn/repo/branch
> > trunk/
> >
> > Which is the same as:
> >
> > $ svn -r1 ls file:///svn/repo/branch@4
> > trunk/
>
> Please double check those as that should not be possible. An ls of the
> branch should not show that trunk is a subdirectory of the branch
> directory, ever, because trunk and branch are both peers in the root. I
> must assume here that you copied the results you stated last time of an
> ls on /repo, and just appended branch to the path without trying it.
>
No, I actually did try it. Please re-read your directions on setting
up the repository.
Your example starts with a checkout the root directory of the repos,
you create trunk and some files within truck, and then copy the WC to
/branch. That is what I did. Therefore you will get trunk as a
subdirectory of branch.
But that is immaterial to the discussion. We are both in agreement
that the contents of branch exist in revision 1 and that branch exists
in revision 4. We disagree about revs 2 and 3.
> > The SVN book states that in this case svn will find branch as it
> > exists in version 4 and trace it back through any renames until
> > revision 1.
>
> Exactly. The problem is that it can trace back to rev 1, but can not
> find it in rev 2 and 3. If it existed in rev 1, and was not deleted in
> rev 2 or 3, then logically it must still exist in rev 2 and 3.
>
> > $ svn -r2 ls file:///svn/repo/branch@4
> > svn: Unable to find repository location for 'file:///svn/repo/branch'
> > in revision 2
> >
> > This makes sense because branch is a copy of trunk version 1.
>
> It does not make sense because if it was a copy of rev 1, then it should
> still exist in rev 2, in a state that is unchanged from rev 1.
>
> > I disagree with this statement. I should only be able to retrieve the
> > state of a file at any revision where it exists. Branch only exists
> > in revisions 4 (when it was actually created) and 1 (because that is
> > the source of the copy).
>
> You have to notice the difference between the name, and the file. The
> NAME of branch was created in rev 4, but the FILE existed prior to
> that. If the FILE existed in rev 1, still exists in rev 4, then that
> file should exist in revs 2 and 3.
>
> Resolving the NAME of /branch can only be done in rev 4, since that is
> the point at which the name was created. This is why ls /branch@3 does
> not work; because in rev 3 that name was not there. Without the peg
> revision though, the name can be resolved in HEAD, and the file did
> exist as far back as rev 1, so logically it existed in all revs in
> between as well, even though it was not changed.
>
I do understand the difference and I understand what you are trying to
say. Personally I don't think it is an issue, sorry.
I did a little digging about this and there wasn't much to find except
this post:
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=34782
Regardless of all that, please see my other post on how to perform the
merge. While you may think that it is sub-optimal it does work.
BTW, you may want to read up on the list about cp WC->URL
functionality. Apparently there are open bugs doing this that you may
want to know about.
:-)
Frodak
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Please don't trim the Cc list.
Frodak Baksik wrote:
> How are you using diff?
svn diff -r3 branch/foo
> I mention it because I don't know how you determined that branch
> exists in revision 1.
If you do NOT use --stop-on-copy then the log of branch shows that it
did exist back in rev 1, under the trunk.
> $ svn ls file:///svn/repo/branch@1
> svn: URL 'file:///svn/repo/branch' non-existent in that revision
You used a peg revision, which is different. The name branch did not
exist in rev 1. When you use a -r instead of a peg revision, the name
gets resolved in HEAD, which works because the name branch exists there,
but you specify that the state of the file should be tracked back to how
it was in a previous rev. This is supposed to work for any and all revs
in the file history back to the point where it was originally created.
> $ svn ls file:///svn/repo/branch@2
> svn: URL 'file:///svn/repo/branch' non-existent in that revision
>
> $ svn ls file:///svn/repo/branch@3
> svn: URL 'file:///svn/repo/branch' non-existent in that revision
>
> $ svn ls file:///svn/repo/branch@4
> trunk/
>
> To me this indicates that file:///svn/repo/branch only exists in
> revision 4.
The NAME only exists as of rev 4, but the file itself existed since rev
one, under the name /trunk. This is confirmed by svn log, and svn ls or
diff with -r1, which works.
> $ svn ls -r1 file:///svn/repo/branch
> trunk/
>
> Which is the same as:
>
> $ svn -r1 ls file:///svn/repo/branch@4
> trunk/
Please double check those as that should not be possible. An ls of the
branch should not show that trunk is a subdirectory of the branch
directory, ever, because trunk and branch are both peers in the root. I
must assume here that you copied the results you stated last time of an
ls on /repo, and just appended branch to the path without trying it.
> The SVN book states that in this case svn will find branch as it
> exists in version 4 and trace it back through any renames until
> revision 1.
Exactly. The problem is that it can trace back to rev 1, but can not
find it in rev 2 and 3. If it existed in rev 1, and was not deleted in
rev 2 or 3, then logically it must still exist in rev 2 and 3.
> $ svn -r2 ls file:///svn/repo/branch@4
> svn: Unable to find repository location for 'file:///svn/repo/branch'
> in revision 2
>
> This makes sense because branch is a copy of trunk version 1.
It does not make sense because if it was a copy of rev 1, then it should
still exist in rev 2, in a state that is unchanged from rev 1.
> I disagree with this statement. I should only be able to retrieve the
> state of a file at any revision where it exists. Branch only exists
> in revisions 4 (when it was actually created) and 1 (because that is
> the source of the copy).
You have to notice the difference between the name, and the file. The
NAME of branch was created in rev 4, but the FILE existed prior to
that. If the FILE existed in rev 1, still exists in rev 4, then that
file should exist in revs 2 and 3.
Resolving the NAME of /branch can only be done in rev 4, since that is
the point at which the name was created. This is why ls /branch@3 does
not work; because in rev 3 that name was not there. Without the peg
revision though, the name can be resolved in HEAD, and the file did
exist as far back as rev 1, so logically it existed in all revs in
between as well, even though it was not changed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
Anyways, in regards to your original question about branching and
merging, Subversion does support the modified WC copy branch/merge
easily enough.
1) Check out the trunk
$svn co file:///svn/repo/trunk
...
Checked out revision 18.
2) Look at the log for whats changed on the branch
$ svn log file:///svn/repo/branch/b2 -v --stop-on-copy
------------------------------------------------------------------------
r18 | fbaksik | 2007-02-15 09:29:53 -0500 (Thu, 15 Feb 2007) | 1 line
Changed paths:
A /branch/b2/another_new_fie
D /branch/b2/bar
M /branch/b2/foo
More b2 branch changes.
------------------------------------------------------------------------
r17 | fbaksik | 2007-02-15 09:25:46 -0500 (Thu, 15 Feb 2007) | 1 line
Changed paths:
A /branch/b2 (from /trunk:3)
M /branch/b2/bar
D /branch/b2/baz
A /branch/b2/new_branch_changes
Branch from trunk v3 with mods
------------------------------------------------------------------------
Note: In the log of r17 the line:
A /branch/b2 (from /trunk:3)
This indicates I need to start the merge from revision 3, not from revision 16.
3) perform the merge
merge -r3:18 file:///svn/repo/branch/ .
$ svn merge -r3:18 file:///svn/repo/branch/b2 .
D bar
D baz
U foo
A another_new_fie
A new_branch_changes
$ svn merge -r16:18 file:///svn/repo/branch/b2 .
svn: Unable to find repository location for
'file:///svn/repo/branch/b2' in revision 16
You can't use r16 because nothing about the b2 branch existed in revision 16.
:-)
Frodak
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/14/07, Phillip Susi <ps...@cfl.rr.com> wrote:
> Frodak Baksik wrote:
> > I've just tried this out. The branch doesn't exist in r1, but only in
>
> svn ls file:///svn/branch -r1 works for me. It shows the contents of
> trunk as of r1, since that was the state of branch in r1, before it was
> copied. You may also try diff instead of ls. The diff fails with r2
> and r3, but works with r1.
How are you using diff?
>
> > r4. From the svn log --help output: "Logs follow copy history by
> > default." This can be changed by using the --stop-on-copy option.
> > Verify this using the ls -R command at different revisions. It'll
> > only show branch in r4.
>
> Not sure why you mention --stop-on-copy, but again, an svn ls -r1
> file:///svn/branch DOES work for me. It only fails with -r2 or -r3.
> You seem to be performing an ls on the root directory, which of course,
> shows no branch in -r1 because it wasn't there in r1, but an ls on the
> branch itself with -r1 works because the branch did exist in r1, just at
> a different path.
I mention it because I don't know how you determined that branch
exists in revision 1.
$ svn ls file:///svn/repo/branch@1
svn: URL 'file:///svn/repo/branch' non-existent in that revision
$ svn ls file:///svn/repo/branch@2
svn: URL 'file:///svn/repo/branch' non-existent in that revision
$ svn ls file:///svn/repo/branch@3
svn: URL 'file:///svn/repo/branch' non-existent in that revision
$ svn ls file:///svn/repo/branch@4
trunk/
To me this indicates that file:///svn/repo/branch only exists in revision 4.
$ svn ls -r1 file:///svn/repo/branch
trunk/
Which is the same as:
$ svn -r1 ls file:///svn/repo/branch@4
trunk/
The SVN book states that in this case svn will find branch as it
exists in version 4 and trace it back through any renames until
revision 1.
$ svn -r2 ls file:///svn/repo/branch@4
svn: Unable to find repository location for 'file:///svn/repo/branch'
in revision 2
This makes sense because branch is a copy of trunk version 1.
> If the branch exists in r4, and did exist in r1 ( under a different path
> ) then how can it not exist in r2 or r3? That is the problem. You
> should be able to retrieve the state of a file at any revision between
> the time it was created ( even if it has since been copied or renamed )
> and HEAD, but in this case, you can not.
>
I disagree with this statement. I should only be able to retrieve the
state of a file at any revision where it exists. Branch only exists
in revisions 4 (when it was actually created) and 1 (because that is
the source of the copy).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Frodak Baksik wrote:
> I've just tried this out. The branch doesn't exist in r1, but only in
svn ls file:///svn/branch -r1 works for me. It shows the contents of
trunk as of r1, since that was the state of branch in r1, before it was
copied. You may also try diff instead of ls. The diff fails with r2
and r3, but works with r1.
> r4. From the svn log --help output: "Logs follow copy history by
> default." This can be changed by using the --stop-on-copy option.
> Verify this using the ls -R command at different revisions. It'll
> only show branch in r4.
Not sure why you mention --stop-on-copy, but again, an svn ls -r1
file:///svn/branch DOES work for me. It only fails with -r2 or -r3.
You seem to be performing an ls on the root directory, which of course,
shows no branch in -r1 because it wasn't there in r1, but an ls on the
branch itself with -r1 works because the branch did exist in r1, just at
a different path.
If the branch exists in r4, and did exist in r1 ( under a different path
) then how can it not exist in r2 or r3? That is the problem. You
should be able to retrieve the state of a file at any revision between
the time it was created ( even if it has since been copied or renamed )
and HEAD, but in this case, you can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Frodak Baksik <fr...@gmail.com>.
On 2/13/07, Steve Bakke <st...@amd.com> wrote:
>
> On 2/13/07 5:48 PM, "Phillip Susi" <ps...@cfl.rr.com> wrote:
>
> > Ryan Schmidt wrote:
> >>> Another way to duplicate this problem is to copy a branch from a
> >>> version other than HEAD. For instance, if HEAD is at 7, and you svn
> >>> copy -r 4 /repo/trunk /repo/branch, then the revisions 5, 6, and 7 can
> >>> not be found in /repo/branch, but 4 can be.
> >>
> >> I'm having trouble following all this, and it would be easier if you
> >> could provide a series of svn commands, starting from creating a new
> >> empty repository, ending with the output that you think is wrong, so
> >> that we can try that same set of commands to see what's going on.
> >
> > I believe the commands I used were something like this:
> >
> > svnadmin init /repo
> > svn checkout /repo
> > mkdir trunk
> > echo foo > trunk/foo
> > svn add trunk
> > svn commit
> > svn update
> > echo bar > trunk/bar
> > svn add trunk/bar
> > svn commit
> > echo baz > trunk/baz
> > svn add trunk/baz
> > svn commit
> > svn update -r1
> > svn copy . /repo/branch
> >
> > At this point the repository head is at rev 4 but you have a branch
> > forked off from rev 1. An svn ls /repo/branch works, but then fails (
> > saying the path can not be found ) if you add a -r3 or -r2, then works
> > again with -r1.
> >
> > If /repo/branch can be found in HEAD, and has history that traces back
> > to rev 1 ( run an svn log on it and it shows the history all the way
> > back to r1 ), then you should be able to find it in all revs between 1
> > and HEAD.
> >
>
> Wow, that's interesting. Whether or not this was intentional behavior by
> svn, it certainly smells like a bug. By definition, that last copy
> operation should have /repo/branch existing at r4.
>
> -Steve
>
I've just tried this out. The branch doesn't exist in r1, but only in
r4. From the svn log --help output: "Logs follow copy history by
default." This can be changed by using the --stop-on-copy option.
Verify this using the ls -R command at different revisions. It'll
only show branch in r4.
$ svn log -v --stop-on-copy file:///svn/repo/branch
------------------------------------------------------------------------
r4 | fbaksik | 2007-02-14 10:56:54 -0500 (Wed, 14 Feb 2007) | 2 lines
Changed paths:
A /branch (from /:1)
Copy WC
------------------------------------------------------------------------
$ svn ls -R -r1 file:///svn/repo
trunk/
trunk/foo
$ svn ls -R -r4 file:///svn/repo
branch/
branch/trunk/
branch/trunk/foo
trunk/
trunk/bar
trunk/baz
trunk/foo
--
Frodak
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Steve Bakke <st...@amd.com>.
On 2/13/07 5:48 PM, "Phillip Susi" <ps...@cfl.rr.com> wrote:
> Ryan Schmidt wrote:
>>> Another way to duplicate this problem is to copy a branch from a
>>> version other than HEAD. For instance, if HEAD is at 7, and you svn
>>> copy -r 4 /repo/trunk /repo/branch, then the revisions 5, 6, and 7 can
>>> not be found in /repo/branch, but 4 can be.
>>
>> I'm having trouble following all this, and it would be easier if you
>> could provide a series of svn commands, starting from creating a new
>> empty repository, ending with the output that you think is wrong, so
>> that we can try that same set of commands to see what's going on.
>
> I believe the commands I used were something like this:
>
> svnadmin init /repo
> svn checkout /repo
> mkdir trunk
> echo foo > trunk/foo
> svn add trunk
> svn commit
> svn update
> echo bar > trunk/bar
> svn add trunk/bar
> svn commit
> echo baz > trunk/baz
> svn add trunk/baz
> svn commit
> svn update -r1
> svn copy . /repo/branch
>
> At this point the repository head is at rev 4 but you have a branch
> forked off from rev 1. An svn ls /repo/branch works, but then fails (
> saying the path can not be found ) if you add a -r3 or -r2, then works
> again with -r1.
>
> If /repo/branch can be found in HEAD, and has history that traces back
> to rev 1 ( run an svn log on it and it shows the history all the way
> back to r1 ), then you should be able to find it in all revs between 1
> and HEAD.
>
Wow, that's interesting. Whether or not this was intentional behavior by
svn, it certainly smells like a bug. By definition, that last copy
operation should have /repo/branch existing at r4.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
Ryan Schmidt wrote:
>> Another way to duplicate this problem is to copy a branch from a
>> version other than HEAD. For instance, if HEAD is at 7, and you svn
>> copy -r 4 /repo/trunk /repo/branch, then the revisions 5, 6, and 7 can
>> not be found in /repo/branch, but 4 can be.
>
> I'm having trouble following all this, and it would be easier if you
> could provide a series of svn commands, starting from creating a new
> empty repository, ending with the output that you think is wrong, so
> that we can try that same set of commands to see what's going on.
I believe the commands I used were something like this:
svnadmin init /repo
svn checkout /repo
mkdir trunk
echo foo > trunk/foo
svn add trunk
svn commit
svn update
echo bar > trunk/bar
svn add trunk/bar
svn commit
echo baz > trunk/baz
svn add trunk/baz
svn commit
svn update -r1
svn copy . /repo/branch
At this point the repository head is at rev 4 but you have a branch
forked off from rev 1. An svn ls /repo/branch works, but then fails (
saying the path can not be found ) if you add a -r3 or -r2, then works
again with -r1.
If /repo/branch can be found in HEAD, and has history that traces back
to rev 1 ( run an svn log on it and it shows the history all the way
back to r1 ), then you should be able to find it in all revs between 1
and HEAD.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 12, 2007, at 10:40, Phillip Susi wrote:
> I understand the preferred method of branching, but why does tsvn
> allow you to branch directly from your wc in one step if this is
> not supported?
"Supported" is an interesting word. It means that someone provides
support for the thing. Subversion is a free product, so your support
system is this free mailing list. We will help you use the product,
or help you understand how to use the product properly. I believe I
did that in my last email, in which I explained that the way to be
able to merge changes from a branch back to the trunk is to have a
revision in which the branch was created, and no additional changes
were made in that revision. You can of course do something different,
such as create a branch and also make additional changes, all within
the same revision. This feature exists, and may be useful in some
situations. However, I don't think it's what you want to do when
you're creating a branch that you want to be able to merge back into
the trunk, because you run into problems such as the ones you're
experiencing.
> Logically it should be the same; causing a copy to be made from the
> BASE rev in your wc instead of the HEAD rev in the repository, then
> committing your changes. In fact, this appears to be what the logs
> of the branch show happened, yet there is a hole in the revision
> history where svn can not find that the files existed, but were
> unchanged since the previous version. The history shows the file
> was copied from version x and modified in version x+y, so why
> doesn't svn infer that the file existed but was unchanged in the
> intervening versions?
>
> The problem only happens if there are versions between the BASE of
> the wc at the time of the copy and HEAD. If the wc is at HEAD when
> you copy it to a branch, everything works fine. Svn can find the
> history flowing back from the commit that created the branch.
> However if someone else has made commits between your last wc
> update and the copy to the branch, those versions in between get
> clobbered in the history of the branch. It does not seem it should
> be possible for a file to exist at point x, and at point y, but not
> to exist in between, when it was neither created nor destroyed in
> that time.
You're right, that wouldn't make sense, but I don't think that's
what's happening. I'm not exactly sure what's happening, but I don't
think that's it.
> Another way to duplicate this problem is to copy a branch from a
> version other than HEAD. For instance, if HEAD is at 7, and you
> svn copy -r 4 /repo/trunk /repo/branch, then the revisions 5, 6,
> and 7 can not be found in /repo/branch, but 4 can be.
I'm having trouble following all this, and it would be easier if you
could provide a series of svn commands, starting from creating a new
empty repository, ending with the output that you think is wrong, so
that we can try that same set of commands to see what's going on.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Phillip Susi <ps...@cfl.rr.com>.
I understand the preferred method of branching, but why does tsvn allow
you to branch directly from your wc in one step if this is not
supported? Logically it should be the same; causing a copy to be made
from the BASE rev in your wc instead of the HEAD rev in the repository,
then committing your changes. In fact, this appears to be what the logs
of the branch show happened, yet there is a hole in the revision history
where svn can not find that the files existed, but were unchanged since
the previous version. The history shows the file was copied from
version x and modified in version x+y, so why doesn't svn infer that the
file existed but was unchanged in the intervening versions?
The problem only happens if there are versions between the BASE of the
wc at the time of the copy and HEAD. If the wc is at HEAD when you copy
it to a branch, everything works fine. Svn can find the history flowing
back from the commit that created the branch. However if someone else
has made commits between your last wc update and the copy to the branch,
those versions in between get clobbered in the history of the branch.
It does not seem it should be possible for a file to exist at point x,
and at point y, but not to exist in between, when it was neither created
nor destroyed in that time.
Another way to duplicate this problem is to copy a branch from a version
other than HEAD. For instance, if HEAD is at 7, and you svn copy -r 4
/repo/trunk /repo/branch, then the revisions 5, 6, and 7 can not be
found in /repo/branch, but 4 can be.
Mark Phippard wrote:
>> You should not create a branch and commit changes to it in one
>> revision. You should split these logically distinct tasks into two
>> revisions.
>>
>> First, copy the trunk to a new branch. That should be the only step
>> performed in this revision.
>>
>> Then, check out a working copy of the branch (or switch an existing
>> working copy of the trunk or any other branch (with changes if you
>> like)) to the new branch. Then make and/or finish up your changes and
>> commit again.
>>
>> Now, when you merge these back to trunk, you start from the revision
>> in which the branch was created.
>
> Ryan's answer covers this well, but if you want to read a more verbose
> version of the same answer, I had a blog post about it a while ago:
>
> http://markphip.blogspot.com/2007/01/shelves-in-subversion.html
>
> Sometimes it helps to read the same thing written multiple ways.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch causes missing revs and errors merging
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 9, 2007, at 15:44, Phillip Susi wrote:
> I have noticed that when I do some work in my working copy and
> decide to commit it as a branch instead, it causes some strange
> problems when I go back to try and merge. Specifically when I
> choose the range of revisions in the branch to merge back into the
> trunk in tsvn, it gets an error saying that it can not find that
> path in rev xxx, where rev xxx is the one prior to the first rev in
> the branch I selected.
>
> I tried merging or even simply listing from the command line as
> well, and this also fails. It looks like what happened is that
> when I forked the branch, it created a hole in the revision
> history. If the trunk is initially at rev 5, and by the time you
> choose to commit your changes as a branch, others have modified the
> trunk and it is now at rev 9, then when you commit your wc as a
> branch in rev 10, the history of /branch does not exist in revs
> 6-9. If you try to svn ls /branch -r9 it fails saying that
> location could not be found in that revision. Same goes for
> revisions 6, 7, and 8, but if you try revision 5, it works
> properly. This causes problems when merging because you try to
> merge using r9 as the start revision because r10 is the first
> commit in that branch containing modifications, you want to track
> the changes including that initial commit. When you manually
> choose r9 or tsvn does ( since it is 1 before the first commit in
> that branch ), you get this error.
>
> Is this a bug and is there any way to avoid it, other than manually
> tracking back to the revision before the hole?
You should not create a branch and commit changes to it in one
revision. You should split these logically distinct tasks into two
revisions.
First, copy the trunk to a new branch. That should be the only step
performed in this revision.
Then, check out a working copy of the branch (or switch an existing
working copy of the trunk or any other branch (with changes if you
like)) to the new branch. Then make and/or finish up your changes and
commit again.
Now, when you merge these back to trunk, you start from the revision
in which the branch was created.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org