Be part of the challenge!

Support merging across files

Right now the samples on the website about splitting up a class are a bit unrealistic since they all include splitting the class up but keeping it all in the same file. In reality, we often move code to different files and still want to merge. SemanticMerge will be revolutionary if it can solve this problem.

94 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Giuliano BGiuliano B shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • James WoodsJames Woods commented  ·   ·  Flag as inappropriate

        The cross file merging would be great but for me the language sensitive cross file difference analysis would be the real benefit in that any large scale method refactors could be reduced to a single line saying that method was refactored.

      • Gerard MurphyGerard Murphy commented  ·   ·  Flag as inappropriate

        Any progress on this yet? ... I saw the video that mentioned this last year, would like to give it a spin...

      • Gerard MurphyGerard Murphy commented  ·   ·  Flag as inappropriate

        I've taken my 3 votes off the feature request: File "branching" to allow new file to track inheritance from previous file.

        I've put them on this instead, as I think this is a much better way of handling the use-case of splitting files discussed in the other feature request.

      • Gerard MurphyGerard Murphy commented  ·   ·  Flag as inappropriate

        Yes, in the past I voted for the ability to support file copies with history in Plastic - my use case was the splitting up of a single source file into multiple files during refactoring - so I could associate the split files with the original as modified copies. However, I'd much rather see semantic merge support this directly, in which case I probably wouldn't need the history-through-copy tracking any more.

        What I had in mind was conceptually concatenating the files (sorted by name) in the before and after changesets into two 'virtual files', then having semantic merge automatically compare the two virtual files - so its code motion would generalise to detecting both file moves / renames as well as code splitting across several files.

      • psantoslpsantosl commented  ·   ·  Flag as inappropriate

        Good point!

        In fact we already have the solution in mind and it is pretty doable.

        The only caveat is that implementing it with Plastic SCM (our own version control) will be a no-brainer but adding support for others will since we will need them to send us additional information and not only the conflicting files one by one.

      Feedback and Knowledge Base