Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18
  1. #11
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    Like I said... how difficult could it be to simply not put them there?

    You are asking the user to jump through hoops to edit something out when a simple runtime parameter could simply prevent the insertion in the first place.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

  2. #12
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    Quote Originally Posted by Craig View Post
    Use /automerge /force, pass the "wait" flag to shell.run, and when the program returns use WSH's RegEx support to find the conflict markers and replace them with just the favored side. The conflict markers look like:

    <<<<<<
    lines from left side
    ======
    lines from right side
    >>>>>>

    So it should be pretty easy to just pull out your favored side.
    I should say that I do appreciate your suggestion. It is a viable work-around and I do plan to use it. I'll watch the return code and programatically edit the merge file and remove the conflict markers if a conflict occurs. However, I do hope for a parameter to prevent this need in the future. Thanks.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

  3. #13
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    I've completed my first run using the "work-around" and have come to the conclusion that just suppressing the conflict markers and their contents won't work. I was wanting to have the same content in the merge file after a command line merge that exists after an interactive merge and save without conflict resolution.

    If you open the merge interactively, one of the input panes is merged into the output pane. Wether it is the center pane or a favored side, I can't be 100% sure...but at least the resulting file contains valid code. If you use /automerge /force, only the left and right sides are displayed within the conflict markers...the center code is not shown at all. So if I remove the conflict markers and the enclosed content, the entire conflict section is missing and the resulting file is not even sytaxually valid.

    I guess I'll drop this request for an enhancement and just use the /reviewconflicts parameter when that functionality is working again.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

  4. #14
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,503

    Default

    I didn't say to supress the conflict marker's content. In between the conflict markers is the content from the left and right side. If you're "favoring" the right side, I'd recommend removing from ">>>>>>" to "======", which would also remove the left file's contents, along with the "<<<<<<" line. That leaves the content of the right file within the conflict section intact, which should at least compile.

    That's not the same as the interactive merge though, since that does a line-by-line merge within the conflict section, but as near as I can tell it does match what you originally asked for.
    Zoë P Scooter Software

  5. #15
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,503

    Default

    Sorry, re-reading the thread I realize I was mistaken about what you're asking for. The workaround I proposed (which isn't what you tried) should end up with a compilable version, but it won't be the same as if loading it interactively and saving it.

    I'm not sure what you're asking for is all that wise though. We can't make any guarantees about the quality of the merge if conflicts occur, so user-interaction should be required, either through the GUI or by introducing the conflict markers. We'll discuss it here though; maybe Tim and Erik feel differently.
    Zoë P Scooter Software

  6. #16
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    Quote Originally Posted by Craig View Post
    Sorry, re-reading the thread I realize I was mistaken about what you're asking for. The workaround I proposed (which isn't what you tried) should end up with a compilable version, but it won't be the same as if loading it interactively and saving it.
    In my last post I metioned that I was withdrawing my enhancement request because I realized that it would not be as simple to implement as I first expected. My initial request was based on some assumptions. I assumed that BC3 already used the /favorright and /favorleft parameters to assist in resolving conflicts both during an interactive merge and an automerge. I guess I was wrong. I am not sure what /favorright and /favorleft really do. It seems to me that they are less useful then they could be.

    Suffice it to say that forcing a save without conflict markers would only be valuable if /favorright and /favorleft are honored. In other words, my proposed /noconflictmarkers option should only be permitted if a user also specified what side to favor. Then BC3 should automatically resolve any conflicts to the favored side and save the merge file without conflict markers. If a /favorright or /favorleft parameter is not specified, a /noconflictmarkers paramerer would need to be ignored.

    Implemented any other way, a /noconflictmarkers parameter woud be useless. You can add the /noconflictmarkers idea to the wish list...but only if BC3 resolves conflicts from the favored side during the forced automerge.

    Thanks again for your patience with me as I explored the automerge capability. I've already assessed that I can programmatically manipulate the forced merge output to my needs (I am aware that I can programmatically preserve the favored side after capturing the error code 14). That will serve my needs for the present.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

  7. #17
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,503

    Default

    /favorright and /favorleft affect coloring in the output. In non-conflicting sections the favored side is drawn with the normal "no change" coloring and the next difference commands don't stop at those sections. We originally added it for Code Co-op; when it calls us for merges it passes the previous revision in as the base instead of a common ancestor, so they only want to emphasis changes that occurred in the most recent revision.

    To get back to your request: Currently when showing interactive merges with conflicts, BC pulls changes from each side on a line-by-line basis, and defaults to the center for lines with differences on all three sides. This works well for trivial "conflicts" where it's just a conflict because two changes are next to each other. It sounds like in your case you want it to take the favored side for the entire conflict, correct? If that's the case that's something we could do for /automerge /force /favorxxx.
    Zoë P Scooter Software

  8. #18
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    Yes, that was my thought...to take the entire conflict based on the favored side. Obviously, the scope of the conflict would be defined by the Session Settings Alignment tab.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •