[snip]
As I said befor the 'User is always right' There are at least
two users out here who don't think "the subversion" way. And since my
background is different from my boss', I suppect we are not the only
ones.
[/snip]
With all due respect, Mr Ford, the adage of the "User is always right"
is one of customer service and support; *not* usability and proper
conduct.
Also, there are probably billions of people who do not think "the
subversion" way. But nobody is obliging a certain mantra. The
processes which Subversion exploits are really evolutionary in the world
of software development. When CVS was introduced, developers went crazy
worldwide! Now Subversion has usurped CVS' capacities and extended them
for even greater current-day utility.
If the methodologies of CVS and Subversion do not agree with yourself,
then perhaps the misunderstanding/issues exist "between the chair and
the keyboard" and not the actual software application. SVN is a boon to
many folks (myself included) and it is not a "subversion" way --
arguably, it is the way of pragmatic software team development!
DISCLAIMER: If anybody was offended, my sincere apologies. It must be
clear that I am not a developer nor sponsor of Subversion; and that the
views expressed herein are *clearly* my own. Should you have any
objections, PLEASE EMAIL ME PERSONALLY. Thank you.
- nasser
Nasser Dassi
Sr. Technical Programmer
=========================================
E: ndassi@141xm.com
=========================================
-----Original Message-----
From: matthew ford [mailto:matthew.ford@forward.com.au]
Sent: Monday, January 24, 2005 12:14 AM
To: users@subversion.tigris.org
Subject: Merger not Merging -- What I would like a merge process to do.
Yes the last one was a real mess. Try this one.
Hi again Ben,
I really appreciate your assistance. It is what keeps me going.
I have never used diff, but have quite happly used CVS merge and it
worked
as ( I ) expected.
This is what I would like 'merge' to do for me (assuming the common case
of
a common ancester)
i) If the file is in the branch:HEAD and was not in the trunk at the
time
the branch was made add it to the trunk:WC if it does not exist.
If it exists in trunk:WC merge differences/conflicts line by line.
ii) If the file is in the branch:HEAD and WAS in the trunk at the time
the
branch but has since been deleted in the trunk:WC then add and mark as
conflict.
iii) If the file is deleted in the branch:HEAD and is still in the
trunk:WC
then mark as conflict.
iv) If the files exist in both branch:HEAD and trunk:WC merge changes
and
mark lines that conflict.
How can I do this using subverion?
Tried to start with
svn diff svn://localhost/svnRepos/trunk
svn://localhost/svnRepos/branches/1
but then was stuck as I don't have a patch command on my machine and
subversion does not supply one.
If you can advise on how to get this result it would be greatly
appreciated.
matthew
=============================================
The following comments deal with you the question you raised in your
email
I thought my second example was quite detailed, basically the branch and
trunk started out the same.
some changes were made to the branch and someone else made changes to
the
trunk.
Now I want to 'merge' the changes in my branch back into the trunk.
>>
>> svn merge --ignore-ancestry svn://localhost/svnRepos/trunk
>> svn://localhost/svnRepos/branch
>> This command seems to copy branch to trunk Not what I expected.
>>
>Like I said, it compares the trunk and branch. If the branch is just
>"trunk plus some changes", then the comparison generates a patch which
>only describes the extra changes. If you run the above command in a
>trunk working copy, the branch changes will be applied.
What I have is branch == trunk plus some changes and latest trunk =
trunk
plus some changes
Cannot seem to get a conflict on the points where the changes intersect.
In the case above there also is no common ancester between
trunk and branch, but you should be able to handle that?
>What the command really does is "compare two trees,
>generate a patch, and apply the patch to a working copy." It's a way
>of replicating changes from one place to another. But it's up to you
>to supply arguments which generate the correct patch. And it's not
>difficult to figure out.
Why do I need to figure this out?
If there is a common ancester why cann't subversion figure it out for
itself.
If there is no common ancester then that should be a unique case which
subversion can recognise.
>You definitely would *not* want the merge command to compare the trunk
>and branch together: that's the classic newbie mistake. See the four
>pargraphs here in the book:
Well actually I do. To do this my hand I would use BeyondCompare to
compare
the trunk to the branch and move the changes from the branch to the
trunk.
I had another look at the docs and comments like
"Again, notice that the commit log message very specifically mentions
the range of changes that was merged into the trunk. Always remember to
do
this, because it's critical information you'll need later on. "
filled me with dread. I think subversion's merge needs to be made
smarter.
I don't really want to have to keep track of my revision history.
I expect subversion to do that for me.
That's why I am using subversion. (Please take this as a constructive
criticism)
>>
>> P.S. I just had a call from my boss who rang to ask how to do a
merge.
>> He cannot get it working either.
>I'm sorry you're frustrated, but making pronouncements that the
>software and docs are bad is not a way to make friends, nor are
>comments like the one above. This isn't a battle, there's no "us"
>versus "you all".
In spite of your best efforts to assist me, (which I really appreciate)
I have been battling with subversion merger for the last
two days.
As I said befor the 'User is always right' There are at least
two users out here who don't think "the subversion" way. And since my
background is different from my boss', I suppect we are not the only
ones. Your comment about "the classic newbie mistake" also suggests
that we are not alone.
How can I encourage the subversion developers to modify the way merge
operates or is documented so that newbie can just use
it stright out of the box?
OK lets try again as before both branch and trunk have been change after
the branch was created.
C:\temp\svnTrunk>svn merge -r 13:HEAD
svn://localhost/svnRepos/branches/1
C oldFileInTrunk.txt
A newInBranch.txt
This almost worked. Now I get a conflict on the change
<<<<<<< .working
This file existed in trunk prior to branch b1 has been modified in
trunk
=======
This file existed in trunk prior to branch b1 has been modified in b1
>>>>>>> .merge-right.r16
but there is no report to tell me that the trunk has deleted a file that
is
in the branch and which the branch may depend on.
I can see why this is so from the command above, as the
command makes no reference to my current trunk. This is probabily the
main
source of the problems I have been having. I want merge to merge the
differences between the current branch and the current trunk.
I don't what to have to care what merges I have preformed
in the past or when the branch was taken from the trunk.
(see statement of need at the top of this email.)
(Also
revert on the merged trunk did not remove the new file added from branch
A newInBranch.txt
so in this regard revert did not revert.)
matthew
---------------------------------------------------------------------
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
Received on Mon Jan 24 15:56:05 2005