John Joseph Bachir wrote:
> > [2] as an experiment i tried this on an export (not checkout)
of
> my code, > and it didn't work. svn complained that . was not a
> working copy. This made > me suspicious since, of course, the
local
> .svn information had nothing to do
>
> We probably need the command you tried here. I personally never
> exported anything from svn, but I would not expect that you need
a
> working copy in order to export a project.
>
>
> Just the command i mentioned.
>
> svn merge -r<previous>:<current> http://example.com/project/trunk
>
> If I do that inside of a checkout of my project, it works. If i do
> that inside of an export of my project, it complains.
Ah. You tried to do a merge on an exported copy of your code, which
failed; the export was fine. And yes, that merge would fail.
Basically, you'd wanted the changes from <previous> to <current> of
example.com/project/trunk into your copy. To do this, you'd need to
either do it within a working copy of your own, or as:
svn merge -r<previous>:<current> http://example.com/project/trunk \
http://svn.johnserver.com/johnbranch/trunk
which does a merge into your repository directly. Svn merge needs to
work on a working copy so it can attempt to find where the changes need
to go, especially if you've already made some local modifications
(similarly, svn diff doesn't work with a non-working copy). If what you
tried were allowed, how would svn merge handle conflicts?
Basically, the svn philosophy is that you shouldn't be making changes
outside of a working copy, and if you decide to do so, that's your own
lookout--don't expect any help from Subversion. :-)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 21 17:17:43 2005