0

I'm working with Subversion 1.7.x, and am doing my development on a branch.

From time to time I merge from trunk to keep the branch up to date.
During the latest merge, though, the incoming code, while totally correct in the trunk, doesn't compile in the branch.
And that's expected, because the code changed in the trunk has partially been rewritten in the branch several revisions ago.

Notice that the merge operation completed cleanly, there were no conflicts.
For the sake of clarity, when I say merge I mean the operation that modifies the working copy with code from another branch, no commit involved, i.e. just the svn merge [source] [dest].

Since that branch will ultimately be reintegrated to the trunk, I guess I have two alternatives:

  1. fix the compilation errors before committing the merged code;
  2. merge from trunk; commit (the merged code without edits); edit the code to fix the compilation issues; commit again (i.e. fix the compilation issues subsequently, performing a new, separate commit).

If I edit the merged code before committing it (i.e. I go with #1), will those changes be lost when reintegrating the branch?

watery
  • 5,026
  • 9
  • 52
  • 92
  • Good question, though it's primarily opinion based and will probably be closed. Might be a better fit for [programmers.stackexchange.com](http://programmers.stackexchange.com) – Patrick Quirk Jul 06 '15 at 15:54
  • @PatrickQuirk Hmm... not as I intended it: I'm worried whether the edits pre-commit would be kept when reintegrating... I'll rephrase the question. – watery Jul 06 '15 at 15:56
  • @PatrickQuirk when referring other sites, it is often helpful to point that [cross-posting is frowned upon](http://meta.stackexchange.com/tags/cross-posting/info) – gnat Jul 06 '15 at 15:56
  • 1
    @PatrickQuirk if a question is primarily opinion-based here, the same applies at Programmers (we have the same close reason). Please read: **[What goes on Programmers.SE? A guide for Stack Overflow](http://meta.programmers.stackexchange.com/q/7182/22815)**. That being said, I am not sure this question is _primarily_ opinion-based. A group of experts would likely reach a consensus. –  Jul 06 '15 at 15:59
  • 1
    I'm voting to close this question as off-topic because it should be migrated to Programmers.SE, except that it would be closed as a duplicate over there of [Is it good idea to require to commit only working code?](http://programmers.stackexchange.com/questions/119784/is-it-good-idea-to-require-to-commit-only-working-code) – durron597 Jul 06 '15 at 16:03
  • @durron597 Even after my edit (reading the linked question)? Anyway, this is not a question about best practices... – watery Jul 06 '15 at 16:04
  • 1
    @watery I do not think it is opinion based. I think it is a good, answerable question, I just think it would be a duplicate if it were migrated. If you don't think it's a duplicate then feel free to edit how it is different. SVN vs CVS is not enough of a difference in this case. – durron597 Jul 06 '15 at 16:05

1 Answers1

1

Short answer is: no, changes will not be lost.

A little bit more details.
Reintegration merge differ from 'regular' sync merge, because it copy branch to trunk, so both become identical[1]. It can be expressed as 'apply difference between branch and trunk into trunk(wc)'. Of course reintegrate merge should actually be reintegrate merge. Subversion 1.8 somehow guess, earlier versions require --reintegrate argument during merge.

Update:

[1] Actually, I made couple tests and found that result will be identical only if you merge into working copy updated to last synced revision. For example, if you sync trunk 1-100 to branch, then create in trunk 10 more additional revisions, then reintegrate branch into trunk - here can be differences.

I personally prefer sync branch to latest revision in trunk, reintegrate and then compare folders for binary identity. Just in case :)

Sergey Azarkevich
  • 2,641
  • 2
  • 22
  • 38
  • Thank you for the useful tips. Yes, I align the branch to the latest trunk before reintegrating too. – watery Jul 30 '15 at 13:00