> Недалёким неведомо что svn up при наличии незакоммиченных изменений в working copy
> делает ни что иное как ребейз [этих изменений на новый head]. это мерж. И более того, явный мерж делается точно так же - через working copy.
Недал...неосиляторам distributed-vcs (для этого необязательно быть недалеким, может и просто повезло, как леночке-проститутке) неведомо, что rebase - это перенос _истории_, а не всех отличий пачкой без разбора. Эгмх...подделка истории, тоись ;-)
Смысла в нем, чаще всего, никакого, просто у тех макак "здесь так принято".
Реальную проблему с svn я уже попытался разжевать: вот лежит у тебя в working copy ДВА разных набора патчей (пусть даже история тебе нахрен не нужна). А может и 22 (у меня в freebsd ports и больше может быть, а история в общем-то не нужна) Не закомичены и не будут - это не твой репо. up их ломает к хренам. Патчи нетривиальные, и чинить их надо строго по одному, и не факт что сможешь оба починить в принципе - возможно, придется радоваться что хоть один починишь. А может изменения апстрима совсем критичные, и надо собрать апстримную версию любой ценой прямо сейчас, а потом уже свое чинить. Что делать будиииим - новаяпапка21, да?
Мелкая проблема - что ты мог просто забыть о своих патчах в working tree, сделать up, и получить поломанное дерево. Теперь ты ни откатить этот up не можешь, ни сохранить свои правки в сторонку, чтобы разобраться с ними как-нибудь потом - состояние до up и кривомержа нигде не сохранено.
git или hg просто дадут тебе по рукам при попытке это сделать. И потребуют явно указать, что предпринять с несохраненными изменениями. Ничто, разумеется, не мешало снабдить подобной проверкой и svn/cvs, но их писали давно, проекты были маленькими, всем было лень напрягаться.
