Announcement

Collapse
No announcement yet.

Text Merge vs. 3-way merge

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tim
    replied
    Yes, that's correct.

    Leave a comment:


  • Dave_L
    replied
    Originally posted by Tim View Post
    The roadmap says 3-way folder merge is expected in 3.?, which means some version 3 release beyond 3.0. It's way too early to say what will be in 3.1. My current guess is that folder merge will make it into 3.1 but that's not solid enough for the roadmap.

    Actually, I'll probably be dropping the features roadmap before the beta goes public. No matter how clear the disclaimer there will be people who consider these to be promises, and they are still quite tentative.
    I assume that, like the 3-way text merge, the 3-way folder merge will only be available in the Pro edition, for both the Windows and GNU/Linux versions?

    Leave a comment:


  • Aaron
    replied
    I've increased the server timeout from 15 minutes to a bit over half an hour. You can also email us any information at support@scootersoftware.com.

    Leave a comment:


  • ron
    replied
    Originally posted by Aaron View Post

    Could you go into more detail (step by step) of what you would like to do with Beyond Compare? Are you calling from Source Control Software?
    Well, I typed in a detailed reply but forgot to save it on the clipboard and when I clicked Preview Post, I was asked to log in again and the reply got lost. So I'll drop this topic.

    Leave a comment:


  • Michael Bulgrien
    replied
    When a 3-way text compare gets brought back into the roadmap, one possibility (special case use) would be to allow a user to launch a three way compare from within the 3-way merge with the left and right input panes read-only, and the output pane in the center of the 3-way compare. I understand that a user would not be able to make changes in the 3-way compare then return to the 3-way merge and undo changes. I think that anybody that wants the functionality bad enough could live with such a limitation.

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Erik View Post
    We can't do that - it breaks the rules of undoability. Also, we filter the input but not the output. In short, it would require a significantly different design to support this.
    As an application developer, I must say that the "We can't do that" argument doesn't go very far. I've been asked to do a lot of things that "couldn't be done" without significant effort. If you can consider adding word-wrap to a future version of BC (which will require additional logic to get the spacing right) then you can consider allowing the user to view the output pane in the center. I never suggested a 3.x implementation. I suggested that it would be a nice addition to a future version of BC (Think BC4).

    Leave a comment:


  • Erik
    replied
    Originally posted by Michael Bulgrien View Post
    gaps can be inserted as needed
    We can't do that - it breaks the rules of undoability. Also, we filter the input but not the output. In short, it would require a significantly different design to support this.

    Leave a comment:


  • Michael Bulgrien
    replied
    Thanks, Tim. I think I misread the roadmap the first time. I went back a few minutes later and noticed that it said 3.?

    I wasn't sure if I misread it the first time...or if you were just super fast in updating it.

    Leave a comment:


  • Tim
    replied
    Originally posted by Michael Bulgrien View Post
    Could you update the roadmap, please?
    The roadmap says 3-way folder merge is expected in 3.?, which means some version 3 release beyond 3.0. It's way too early to say what will be in 3.1. My current guess is that folder merge will make it into 3.1 but that's not solid enough for the roadmap.

    Actually, I'll probably be dropping the features roadmap before the beta goes public. No matter how clear the disclaimer there will be people who consider these to be promises, and they are still quite tentative.

    Leave a comment:


  • Michael Bulgrien
    replied
    I would not expect the pane to be moveable without a redraw...in which case the gaps can be inserted as needed when the output pane is viewed in the center pane.

    Leave a comment:


  • Erik
    replied
    FYI, if we just moved the output pane to the middle, lines would not necessarily line up - the output can have extra lines inserted throughout. Whenever a line is output only, all 3 input panes would have to have a gap. In order for the output pane to be movable, those gaps would have to always be there.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by Michael Bulgrien View Post
    It is easier to compare panes that are side by side. Instead of having a separate output pane, one merge engine I tested allows you to swap between viewing the common ancestor and the merged output in the center pane. Although I don't have a problem with the current implementation, it would be nice if a future version of BC provided that flexibility to users that prefer not to have the forth pane.
    I second this. When I've finished merging/editing the merge output, it would be nice to be able to compare the merged result to left/right side-by-side so I more easily can validate the final merge result before accepting changes.

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Craig View Post
    No, n-way folder compares would have (will) extended the current 2-way folder comparison to include to a larger number of sides. Think a single source directory and a bunch of target directories.
    Thanks! I just got confused since n-way folder compares and flattened folders were on the same line in the roadmap. My bad.

    Originally posted by Craig View Post
    Yes, it's intended, though it could be changed based on feedback. If a file is lined up with something it will overwrite it; if it isn't it always goes in the base folder. Copying unaligned files is a bit up in the air; we could copy the folder structure if it already exists, but I think we'd have to keep the current behavior if the target directory didn't exists, which would make things a bit inconsistent. Plus, if the folder structures are the same on both sides, why are you using the flattened view?
    I thought that flattened folders might make it easier to compare/sync deep folder tries that, when fully expanded, cause you to have to scroll left or right to view their contents. I tried it, but all my orphans on the left side ended up in the base folder on the right.

    I can see the advantages of copying to the base folder. I don't think that orphans with matching folders should be copied into their matching folders if orphans without matching folders are copied into the base folder. That would indeed be an inconsistency. I can see the advantages of being able to copy all files to a base folder on the other side. I am just wondering how many people will try something like I did.

    Leave a comment:


  • ZoŽ
    replied
    Originally posted by Michael Bulgrien View Post
    Also, I take it the current flattened folder feature is the "n-way folder compares" listed in the roadmap?
    No, n-way folder compares would have (will) extended the current 2-way folder comparison to include to a larger number of sides. Think a single source directory and a bunch of target directories.

    Originally posted by Michael Bulgrien View Post
    What I did not realize about the flattened folders is that when I copy something from one side to the other, it does not copy into the same folder structure on the other side even if the same folder structure exists. With flattened folders, all files are copied to the base folder on the other side. Is this the intended behavior?
    Yes, it's intended, though it could be changed based on feedback.

    If a file is lined up with something it will overwrite it; if it isn't it always goes in the base folder. Copying unaligned files is a bit up in the air; we could copy the folder structure if it already exists, but I think we'd have to keep the current behavior if the target directory didn't exists, which would make things a bit inconsistent. Plus, if the folder structures are the same on both sides, why are you using the flattened view?

    Leave a comment:


  • Michael Bulgrien
    replied
    It is easier to compare panes that are side by side. Instead of having a separate output pane, one merge engine I tested allows you to swap between viewing the common ancestor and the merged output in the center pane. Although I don't have a problem with the current implementation, it would be nice if a future version of BC provided that flexibility to users that prefer not to have the forth pane.

    Leave a comment:

Working...
X