On Sat, 6 Aug 2005 01:38, Nathan Kidd wrote:
> 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?
***NOT TESTED***
svn help cp implies that "svn cp -r BASE wc mybranch" is valid. This
(hopefully) will do the right thing with regard to mixed revision wc. (If it
doesn't, -r COMMITTED is also a possibility). Even if the command line can't
do a copy of cp -r BASE wc URL, the api might be able to.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Aug 5 23:44:15 2005