On Apr 25, 2011, at 09:34, dov.kru...@americas.bnpparibas.com wrote: > Excuse my ignorance, I'm used to cvs.
I have never used cvs, so my advice may not exactly correspond. > I edited some files at the same time as a colleague, but when we realized, he > went forward, so my copies were obsolete. Not necessarily. You might have made changes to different parts of the file, which subversion would have resolved for you, in a probably proper manner. > Some time later, I tried to update, to get the new files, and to get his > updated version. > > It reported the files changed, just as I would see in cvs: > > C A.txt Ok, a conflict occurred, so you and he did modify similar-enough parts of the file that subversion could not automatically merge them. You would now usually resolve the conflict manually. http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle.resolve You usually do this by opening the file in an editor and picking the correct lines from amongst those subversion has indicated in the file for you. You can also make use of the three additional files subversion has created (one containing the old file, one containing the new upstream file, and one containing your version) to assist you in deciding what's right. > Since I wanted the new ones, I first looked for the equivalent of > > cvs up -C > > thinking it was: > > svn up --force > > but it wasn't. > > So then I deleted the files (so I don't have a local copy at all) and again: Ok, now you don't have the file at all. > svn up > > Subversion just reports the current version number and does not try to bring > the files in as cvs would. This should indeed have brought back the current version of the file. Are you sure it did not?
