svn && eclipse
В нее ткнешь, и будет тебе гуевый 3-way merge
Я уж все настройки излазил... особенно ветку с svn. И все без результатно...
В Subclipse должно быть что-то подобное, если нет, можешь попробовать Subversive.
субверсив ставь
и эклипс последний ставь
и потом, вместо аплейта можна делать тим синхронайз и уже тама сомтреть какие есть конфликты
Я просто решил, что раз от автороров svn, то лучше он. Спасибо, попробую subversive.
"от авторов" IDE плагины лучше обычно.
в контекстном меню конфликтного файла разве нету?
Есть она там. Только там мердж лишь в одном направлении - можно перенести серверные изменения себе, а не наоборот (что в принципе логично). Проблема в том, что в Subclipse если после мержа, я нажимал "mark as resolved", оставив свои изменения (хочу отменить серверные и принять свои а потом коммитил, то оно заливалось прямо в таком виде с "<<<<<<< .mine" и прочим. В Subversive, я проверил, это не так - там после нажатия "Mark as Merged" принимаются мои изменения, а потом они благополучно заливаются на сервер.
Если я унесу с собой на флешке код проекта, а затем принесу измененный, то у Microsoft TFS есть такая возможность "Check Out for edit" - он проверяет все изменения и потом корректно заливает их на сервер. Как сделать подобное с subversive и subversion? Если просто вставить новый вариант проекта на место старого, потом сделать Refresh, team - update, team - commit, то он просто зальет все мои изменения без мержа (отменив все чужие изменения).
И второй вопрос: можно ли через subversive отменить только что внесенный мною коммит?
Mark as resolved означает, что ты уже вручную слил изменения и хочешь сообщить об этом subversion. Если ты хочешь оставить свои изменения, то тебе нужно скопировать файл .mine поверх файла с конфликтами, а затем нажать mark as resolved. Вообще-то это стандартный способ работы с конфликтами в svn.
то он просто зальет все мои изменения без мержа (отменив все чужие изменения).Нет, Update зальет тебе чужие изменения (возможно создав конфликты) и потом ты закоммитишь уже с ними. Более того, можно даже сразу делать commit - если ты пытаешься залить файл, который кто-то успел изменить, то тебе выдадут ошибку, в которой попросят сделать update.
скопировать файл .mine поверх файла с конфликтами, а затем нажать mark as resolved. Вообще-то это стандартный способ работы с конфликтами в svn.Какой-то через одно место метод. Особенно с учетом того, что в этом случае Subclipse при нажатии commit зальет сначала то, что файл был удален, а затем если еще раз закоммитеть, что создан новый файл с таким же именем и соотв. содержанием. Работа с конфликтами у Subversive мне явно понравилась больше.
А Drag&drop в package explorer'e разумеется использовать для разрешения конфликтов не нужно (лично у меня даже мысли никогда не возникало его использовать в таком случае - но я читал книгу по svn).
Учу копировать в этом случае: открываем файл с конфликтами, ctrl+A, Ctrl+X. Открываем наш файл (*.mine): ctrl+A, Ctrl+C. Открываем файл с конфликтами: ctrl+Vне очень хороший метод
ну тойсть он не всегда может быть применим
например может быть установлена опция: автоформатировать только измененные строки
это для того, чтобы при коммите весь файл не разукрасился радугой
в твоем способе измененные строчки будут все
Не уверен. Вот только что взял чужой исходник в svn'e (отформатированный по другим правилам удалил весь текст, вставил, сохранил - никакого форматирования не применилось, хотя опция format edited lines в save actions стоит (только импорт отформатировался, благодаря соотвествующей галочке). Так что отформатируются максимум места конфликтов.
Оставить комментарий
dangerr
Поднял VisualSVN Server на Win2003, на eclipse поставил плагин Subclipse. Все бы ничего, но когда появляются конфликты, то нажатие Update приводит к тому, что в сам код вносятся такие вот изменения:при этом рядом появляются файлы SvnJava.java.mine SvnJava.java.r36 SvnJava.java.r37 c различными вариантами кода.
Единственный найденный мною способ принять собственные изменения - удалить файл SvnJava.java, перименовать SvnJava.java.mine в SvnJava.java, отметить как разрешенный конфликт и 2 раза закомитить.
Думаю должен быть более прямой способ разрешения конфликтов.