Trevor Harmon wrote:
> Hi,
>
> Occasionally I come across an unfortunate scenario where I've got two
> copies of a directory: an old one checked into a repository, and a newer
> one that happens to exist entirely outside of Subversion (not in a
> repository or working copy). The new one has just a few scattered
> changes compared to the old one.
>
> My goal is to merge the two directories so that the old one is updated
> with all of the new's changes. With a single file, this task would be
> easy: I'd simply replace the working copy with the new file, then check
> in the change. With a directory, however, it's a lot more complicated. I
> can't just replace the old version's working copy with the new directory
> because that would wipe out the .svn metadata. Instead, what I've been
> doing is this:
>
> svn remove mydir
> svn ci mydir
> [copy the new mydir into current directory]
> svn add mydir
> svn ci mydir
>
> Although this works, it has the disadvantage of splitting what should be
> a single repository commit into two. If mydir is large, there will be
> two large changesets for each commit, even if only a small portion of
> the directory has changed.
>
> Is there a better way of handling this? Thanks,
I'd just copy the changed files over to the working copy and commit.
Something like:
cd other_copy
rsync -av . /path/to/working_copy
should do it. You can add the -n (dry-run) option to preview what will
happen without actually doing it first, and if the source of the copy
also is a checked out version with subversion metadate, add the
--cvs-exclude option (which also knows about svn).
If new files have been created in your other copy, you'll have to 'svn
add' them to commit.
--
Les Mikesell
lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-27 17:13:28 CET