On Feb 10, 2006, at 22:29, Matt England wrote:
> And yes, we have email notifications for all our commits (to try
> and catch these rogue changes)...I just wasn't paying close enough
> attention to what was going on when it happened. But again, I ask:
> how does one revert committed changes? Where/how is this magic done?
To undo changes, you do a so-called reverse merge:
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.2
On Feb 10, 2006, at 20:27, Matt England wrote:
> So it appears that, at least in this context, a merge is not a
> recursive diff. Is this a correct statement? In this same
> thought: it's probably obvious that I'm still very unfamiliar about
> what subversion *is* and *is not* doing with respect to merges (and
> I realize the Lieven and Ryan and possibly others are trying to
> tell me...and the info is trying to seep through into my brain). I
> hear that that there is no merge tracking...but that there is a lot
> of special things that merge does from diff. I'm finding myself
> thoroughly confused, in part because I don't yet understand why
> some merge intelligence would be put in without "all" the
> intelligence, but I suspect I will learn more about this if I
> choose to continue to study it (which might be hard to find time to
> do at this point).
Merging can be tricky to understand, but there's no magic or
intelligence going on. I like to offer this explanation which I've
been told is helpful:
A merge creates a set of steps [1] needed to get from A to B,
and performs those steps on C.
Consider that you created a branch from the trunk at revision 100.
Now it's revision 200, and there have been many changes [2] on the
branch, and other changes on the trunk. Now you want to merge the
branch back into the trunk. How would you formulate this task using
the A-B-C model above? Well, you want to start with the branch at
revision 100, when it was created. You'd want to write down the steps
needed to get to revision 200 of that branch. Then you'd want to
apply all those steps to an up-to-date and otherwise unmodified
working copy of trunk (and then test those changes and then commit
them). So you'd run:
svn merge -r 100:200 \
url://to/repository/project/branches/the-branch \
/path/to/working/copy/of/trunk
In this command, A is revision 100 of the branch, B is revision 200
of the branch, and C is the working copy of trunk.
You can (and most people usually do) omit the path to the working
copy, because if you omit it, Subversion uses the current directory.
So if you were already in the working copy of trunk, the command
reduces to:
svn merge -r 100:200 \
url://to/repository/project/branches/the-branch
[1] A diff. Internally, Subversion diffs do handle all differences,
including properties, the adding and deleting of entire files and
directories, and everything else Subversion keeps track of. Now, if
you actually go and type "svn diff," the textual display format is
not rich enough to be able to represent all these operations at this
time, so some types of operations (like directory adds or removes)
are not shown there. Rest assured, however, that when a diff is
computed as part of a merge that *all* changes are being handled.
[2] And let's say for the moment that these changes don't include
reorganizations as happened in your case, but rather are simply
changes to existing files, without moving them around.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 10 23:01:59 2006