On May 3, 2006, at 23:36, John Joseph Bachir wrote:
> let's say i have my project:
> and an external:
> and they both have myfile.php. if i perform this action, with 1.3.1:
> cd trunk
> svn merge -r5:10 ../otherproject/myfile.php
> svn does not complain.
> furthermore, if i use revisions that are out of bounds for my
> project, it does not complain; if i use revisions that are out of
> bounds for the external, it DOES complain. so i know that it is
> using the versions of the external when calculating the diff.
> question: is this directly supported by svn or is it just a fluke
> that it works?
I don't know... IMHO it should be supported.
> [a] if it is supported, what else is supported? can i do svn cp
> operations from externals into my main repository and svn will
> remember the history of the file as coming from the external?
No, copying from another repository cannot work, and cannot be made
to work, according to a recent statement on this list by someone I
> [b] if it is not supported, is it strongly discouraged due to
> metadata in my main repository becoming corrupt/meaningless, or is
> it safe enough, and serves as a convenient replacement for doing
> diff and patch manually?
Doing a merge is no different than doing changes by hand. Subversion
doesn't know the difference, after the merge has been done. So I
don't see any reason for it to mess anything up or be unsupported. It
seems like a great way to update a local vendor branch, for example,
when the external project itself already uses Subversion. Would save
the trouble of maintaining a local copy of their original source.
Now, if the remote repository and your own are served using different
protocols (maybe yours uses https and theirs uses http, for example),
then you get a message that mixing protocols is not supported at this
time, though I can't see any reason why the protocol should matter...
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu May 4 14:36:19 2006