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.
**