Ben Gollmer <ben@jatosoft.com> writes:
> > Jack simply applies her change to his working copy using 'svn merge':
> >
> > svn merge -r52:53 path/to/project my/working/copy/path
> >
> > This means, "take the differences between revision 52 and 53 of
> > path/to/project, and apply these differences as local modifications to
> > my/working/copy/path."
> >
>
> So instead of "marshalling revisions into a blob" to pass them between
> repositories, Jill can just tell Jack to grab changeset 53 (i.e. the unique
> patch applied at rev 53) from her repos. He can then merge the changes into
> his own repos whenever he feels like it. Right? Or am I missing the point of
> revision blobs?
Well, yes, you're doing the next step. After Jack applies changeset
53 as a local-mod to his working copy, he's free to commit the local
mods. Now that change is officially the HEAD revision in his own
repository.
But the 'svn merge; svn commit' technique is also useful within the
same repository, especially for *removing* changesets. Suppose HEAD
is currently revision 70, and now you decide that r53 was a bogus
change. You want to revert it. So simply apply the diff in *reverse*
to your working copy, and commit that local mod:
svn merge -r53:52 path/to/project my/working/copy/path
svn commit
And now the new HEAD, r71, is exactly like r70, but with changeset 53
missing.
Of course, 'svn merge; svn commit' is most often used to port changes
between locations in the same repository... i.e. porting (replicating)
a change from /branch/janes-branch/ to /trunk, or whatever.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 10 06:22:43 2002