For the (hopeful) benefit of Simon going over this thread...
Nathan Kidd wrote:
> If the branch is created from anything but your working copy
> then if, for example, you add a file in your WC and then switch to your
> branch it will "un-add" the file and you'll have to re-add it again
> after the switch. Same goes for deletes. So you pretty-well need to
> copy from your WC to URL, and then revert.
This is not strictly true. I was actually testing something slightly
different. *Scheduled* adds and deletes do survive across switches, but
if your branch is created from a revision before a modified file in your
WC was added then the switch will leave you with an unversioned file.
The "svn cp wc mybranch" approach can capture your mixed WC state
exactly, but "svn cp url mybranch, switch", cannot. The real problem
then is: What revision of the URL do you use when creating the branch?
If you consider the following situation:
r10 has file1.txt and file2.txt, you check out to your WC
r11 someone else modifies file2.txt, you don't update
r12 you add file3.txt
WC has modified file2.txt and file3.txt
Running svnversion says:
10:12M
If you create the copy from trunk @ r10 then you can have a problem
because after the switch to mybranch (which doesn't have file3.txt in
it) you end up with an unversioned file3.txt that cannot be committed
without another add -- not what we want.
So what about we copy trunk @ r12 to create the branch?
This avoids the problem with file3.txt not existing, but when you switch
you're effectively running an update to r12 (so the r11 changes to
file2.txt will be merged, and you will have to resolve any potential
conflicts before committing). This is exactly what Mark's just-prior
(thread-wise) post pointed out.
This update/potential-conflict-resolution would have to be done at some
point anyway (if you ever were to use the changes), but I think half the
point of "shelving" is to easily set aside your changes so you can work
on something else -- a poor time to be forced to resolve conflicts.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Aug 5 17:38:51 2005