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

Re: Update deleted local changes after rollback

From: Ulrich Eckhardt <eckhardt_at_satorlaser.com>
Date: Thu, 12 Aug 2010 17:13:48 +0200

On Thursday 12 August 2010, erlend olsen wrote:
> repository has these files:
> xyz
> A: commits changes to all the files and adds 2 new files
> repository now has these files:
> pqxyz
> B: Sees that these changes f**ks up the whole program and he rollbacks to
> only x,y,z

I guess he reverse-merge the according revision or manually reverted the
changes. It shouldn't matter.

> A: keeps his changes locally and keeps changing them until they
> work...

Both A and B should have first talked with each other. A would then have
created a branch probably.

> B: commits new code.
> A: is happy because now everything works on his local copy. Then he pushes
> 'update' in netbeans before he commits..... SVN: now deletes all of A's
> changes and new files..

I don't think so, as SVN tries very hard to preserve any user changes. If a
file was deleted in the repository, SVN won't delete a local copy of a file
if that contains modifications. If a file was modified, and those changes
conflict with local changes, SVN will notify the user of this and attempt at
resolving the conflict, but it first moves all three versions to separate

> A: screams in terror and tries to get back his files... but not a chance...
> He can get the changes he committed before the rollback, but the real big
> changes are now deleted....

As I mentioned, SVN preserves those changes unless explicitly asked to throw
them away (some "--force" options on the commandline). I don't know what
netbeans' update button does. Also, if there are conflicts (I'm sure SVN
would have complained), you can always choose "resolve using theirs", which
implies that your own changes are discarded. If your colleague chose that,
it's a user error.

> Its about 1 week of programming down the toilet...

Going one week without proper version control, without being able to backstep
any changes, without the benefits of a centralised backup system, without
updating the own WCs to see if changes conflict? Don't do that.

Note that if you had created a branch, you could have done these extensive
changes in separation but still with version control etc, you should learn
that. However, it still remains to find out what steps exactly lead to this
data loss.



ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
           Visit our website at <http://www.satorlaser.de/>
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
Received on 2010-08-12 17:14:25 CEST

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

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