Raman Gupta wrote:
> Wayne wrote:
>
>> Wayne wrote:
>>
>>> The plot thickens. First the requested output:
>>>
>>> >svnmerge avail -vv
>>> svn --non-interactive propget --strict "svnmerge-integrated" "."
>>> svnmerge: calculate source path for the branch
>>> svn --non-interactive info "."
>>> svnmerge: source is "http://xxxx/branches/my_branch"
>>> svn --non-interactive propget --strict "svnmerge-integrated"
>>> "http://xxxx/branches/my_branch"
>>> svnmerge: command execution failed (exit code: 1)
>>> svn --non-interactive propget --strict "svnmerge-integrated"
>>> "http://xxxx/branches/my_branch"
>>> svn: 'http://xxxx/svn/branches/my_branch' does not exist in revision '71'
>>>
>>> >svn pl --verbose "http://xxxx/branches/my_branch"
>>> svn: Unknown node kind for 'http://xxxx/branches/my_branch'
>>>
>>>
>>> Now if I run the prop get myself like this (my working copy was last
>>> updated at version 68):
>>> >svn propget "svnmerge-integrated"
>>> /branches/my_branch:1-4
>>>
>>> At this point I noticed that some check-ins had happened so I did an
>>> svn update. Now my working copy is at revision 71. Now if I run the
>>> command 'svn propget "svnmerge-integrated"' I get and empty line.
>>>
>>> The unknown node type response to the pl command concerns me. However,
>>> svnadmin verify does not report any errors.
>>>
>>>
>>>
>> I was just thinking about this and I remembered that I actually moved
>> the branch after I made it. Could that be what's causing the problem?
>>
>
> While moving the branch will definitely cause svnmerge.py to fail
> (unless the integrated property is modified to match), I don't see how
> moving the branch would cause the particular symptoms you are seeing.
> svnmerge.py would just treat the moved branch as uninitialized.
>
>
>> If this is the case then I think that I make a new branch (copy the same
>> revision to a new branch name), run svnmerge init and then copy all my
>> changes over. Then I will have another branch at the same point. Then I
>> can start merging to/from the trunk. Do you see any problems with this?
>> I am not really worried a lot about the history in the branch up to this
>> point.
>>
>
> I don't really understand what you are doing here. But if you are
> essentially proposing to initialize merging from a new branch, just
> remember that as far as svnmerge.py is concerned thats a completely
> new branch with no shared revisions with any other branch (except for
> the one it was copied from).
>
> Cheers,
> Raman
>
>
Our companies version control policies don't allow check-ins of anything
until a feature is complete and the code has been tested and reviewed. I
am working with another off-site developer and we are using subversion
to share our code. We started with a repository that looks like this:
project
/ \
trunk branches
\
feature_branch
It's not really relevant but we have working copy that is checked out
under both version control systems. When someone updates the project in
our company version control system we check-out the changes and then
check them into subversion. That's were changes to the trunk come in.
Anyway, we decided that instead of 'feature_branch' we wanted to add
'developer_a' and 'developer_b' directly under branches and then moved
the 'feature_branch' directory to 'branches/developer_a/feature_branch'
Now we have 3 weeks of work and a little more time right now so we
wanted to try and figure out how to use svnmerge because it looks like
it will help us keep our 'feature_branch' up to date with changes in the
trunk.
It is at this point that I ran 'svnmerge init' and 'svnmerge avail' The
integrated property was created long after the move and after 3 weeks of
working on the branch.
At this point I want to get svnmerge to work. I am wondering if I create
a new branch from revision 4 (the point were the 'feature_branch' was
created), then run 'svnmerge init', then copy over all the changes from
'feature_branch' if I can then get svnmerge to merge all the changes
from the trunk, since version 4, into my new branch.