#3 Branch should be captured with changeset

open
5
2004-02-24
2002-11-29
Anonymous
No

By looking at a changeset, there is no way to tell
which branch it came from. It would be nice to have
the ability to see this in the recent/important
checkins page, as well as possibly filtering this by a
dropdown of some sort on the page. I took a look at
how this might be done, but it looks like more than
just a trivial change (possible metadata change).

By the way, thanks for such a great application. Sorry
about overwhelming you with suggestions and reports. :)

Discussion

1 2 > >> (Page 1 of 2)
  • Adam Kennedy
    Adam Kennedy
    2002-11-29

    • labels: --> 474215
    • assigned_to: nobody --> adamkennedy
    • priority: 5 --> 3
     
  • Adam Kennedy
    Adam Kennedy
    2002-11-29

    Logged In: YES
    user_id=153576

    Branch information is captured, but current discarded for
    memory reasons. The main problem with branches is that they
    apply per-file, and the ChangeSet reverse engineer'er would
    have to do a few extra things.

    It should be possible, but not until 0.7. It won't make it
    into the 0.6.X series, as I don't want to break MetaData
    compatibility in minor increments.

     
  • Adam Kennedy
    Adam Kennedy
    2002-12-03

    Logged In: YES
    user_id=153576

    Moving to feature requests

     
  • Adam Kennedy
    Adam Kennedy
    2002-12-03

    • assigned_to: adamkennedy --> nobody
    • labels: 474215 -->
     
  • Adam Kennedy
    Adam Kennedy
    2003-01-21

    • assigned_to: nobody --> adamkennedy
     
  • Logged In: YES
    user_id=385376

    If you can work with me, I have been allocated about 120
    hours to work on handling branches for both changelists and
    the data used to generate the graph.

     
  • Adam Kennedy
    Adam Kennedy
    2004-02-24

    Logged In: YES
    user_id=153576

    Alrighty. Starting point is to create a simple module with
    half a dozen files and a branch or two.

    Then go look in CVSMonitor/Bankend/CCVS.pm at

    * Lines 10-27
    * Lines 90-98

    Those are what controls branch parsing the inclusion.
    Adding "branches" to %USABLE_FILE_KEYS should get you the
    data into the CVSMonitor::MetaData::File objects...

    A ->branches method in CVSMonitor::MetaData::File probably
    also needs to be added... See how you go once the data is in
    the objects...

     
  • Adam Kennedy
    Adam Kennedy
    2004-02-24

    • labels: --> Interface Improvements (example)
    • priority: 3 --> 5
    • assigned_to: adamkennedy --> mpechner
     
  • Adam Kennedy
    Adam Kennedy
    2004-02-24

    Logged In: YES
    user_id=153576

    Because the metadata is just saved via Storable, it's safe
    to add additional hash entries to the File, Version and
    ChangeSet objects, as they would be ignored if not used.

    But you are right that the File -> Version -> ChangeSet
    algorithm will need to be modified.

    Using the raw data in the File object, you probably need
    have each new Version determine if it's in a branch, and
    what that is, and save it in the Version (
    $Version->{branch} ??? ).

    I would implement it AFTER the block of code that populates
    the ->{previous} values, at

    CVSMonitor/Backend/CCVS.pm: 321-357

    You might just be able to make it happen DURING that block (
    maybe... ) at or near line 342

    if ( exists $version_index{$previous} ) {
    ### Could we determine branch information here?
    $version_index{$revision}->{previous} = $previous;
    last; # Exit the while
    }

    In that point, you have access to the File via $parent, and
    we know already it isn't on the HEAD. Maybe we could trace
    upwards at that point, it does go in order ( I think ) from
    trunk to branch ( or rather commit order, but that amounts
    to the same thing ).

    Having done THAT, we need to decide on the behaviour if
    someone does a commit that spans, or appears to span,
    multiple branches, remembering the ChangeSets are only
    derived heuristically ( although relatively accurately ).

    THAT finicky piece of logic is at

    CVSMonitor/MetaData/ChangeSet: 73-121

    If we allow multi-branch commits, then determine "which
    branch a ChangeSet is on" gets damn hairy, because
    technically, it's on multiple. Otherwise, you just set the
    $ChangeSet->{branch} somewhere around there to whatever
    value the first ( or any ) of the versions inside it are.

    Personally, I'm in favour of "commits are only on a single
    branch", but I do see where that could cause some problems.
    I think there might be problems either way... as a starting
    point, ask around the developers at your office to see if
    anyone's ever done it.

    That should give you enough to get on with :)

     
  • Logged In: YES
    user_id=385376

    do you have a debug or object dump method so I can pass
    output to the screen, or add items to the logs?

     
1 2 > >> (Page 1 of 2)