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 files. > 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. Sorry! Uli -- 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. **************************************************************************************
