[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Subclipse prevents refactoring

From: W Craig Trader <ct7_at_unicornsrest.org>
Date: 2006-03-02 15:03:00 CET

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

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.