Yup, that was the problem! I deleted the /classes dir,
then did a check-out again (since I had no changes
out, I just rechecked out the entire project). From
now on, a full update on the root project dir works.
--- Mark Phippard <MarkP@softlanding.com> wrote:
> Kevin Duffey <email@example.com> wrote
> on 09/13/2005 03:43:47
> > So thinking about this, it's obvious the
> > WEB-INF\classes shouldn't be in subversion because
> > generated via our build, however for some reason I
> > have it in there. When I do a full build, it wipes
> > anything in the /classes directory to do a clean
> > build. I think the reason I included it was that I
> > generally wasn't creating the /classes dir in my
> > script.
> > Anyway, this makes it impossible for us to update
> > anything. While I can somewhat understand why it
> > occur, it kind of sux that it prevents all the
> > dirs from being updated. It's as if subclipse (or
> > subversion?) goes through all dirs first looking
> > locks, then goes to the server. We now have to
> > on about 8 different locations and do updates
> since we
> > can't just update the whole project in one shot.
> > Any help on what I may do to fix this would be
> > appreciated.
> This is all done by Subversion. When folders that
> are under control of
> Subversion just get deleted in the filesystem the
> working copy becomes
> corrupt. You need to get the classes folder out of
> your repository.
> Checkout your project outside of Eclipse and run svn
> delete to delete that
> folder and then commit.
> Then re-checkout inside Eclipse. When the classes
> folders is recreated by
> the build, add it to the svn:ignore property of the
> WEB-INF folder and
> commit that change.
> Then have everyone re-checkout.
> Scanned for SoftLanding Systems, Inc. and
> SoftLanding Europe Plc by IBM Email Security
> Management Services powered by MessageLabs.
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Yahoo! Mail - PC Magazine Editors' Choice 2005
Received on Wed Sep 14 09:28:31 2005