On Fri, 2006-03-03 at 00:46 +1100, Karl Auer wrote:
> > > svn: Cannot copy or move 'XXX' it is not in the repository yet;
> > > try committing first
> > > It might be that there are technical problems that have to be solved,
> > > but committing (as proposed) is not acceptable, since this would mean
> > > to commit a source code that is totally screwed
>
> Committing stuff that's screwed is not a major problem really - just
> make sure your commit message says "don't use this revision" and says
> why.
One problem with this approach is that if you use continuous integration
(such as CruiseControl or AntHill) to monitor your repository and build
after a series of commits, this will break the build something fierce.
> You could also do it the way vendor branches are handled (look in the
> book under "Vendor branches"): Copy your working directory out to a new
> (unmanaged!) location, modify it there until you are happy with it, then
> copy it back over your working copy. New stuff will be automatically
> detected at commit time, modified stuff too, but you will have to
> manually do a Team->Add on any new directories and such. Then commit. If
> there are re-used directory names or re-used names in there, then there
> is really no way around doing interim commits.
This may work, but wouldn't it cause you to lose this history for each
of the moved/renamed files?
It may be too late in this instance, but in the future this sort of
exercise (major refactoring) is an excellent reason for using
non-release branches. Branch before starting your refactory, switch
your workspace, do everything you need to do, and then finally merge the
branch back into the trunk, and then get rid of the branch.
- Craig -
--
W Craig Trader <ct7@unicornsrest.org>
Unicorn's Rest
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Mar 2 15:03:59 2006