#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

  • 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
     
  • Michael Pechner

    Michael Pechner - 2004-02-24

    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 :)

     
  • Michael Pechner

    Michael Pechner - 2004-02-24

    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?

     
  • Michael Pechner

    Michael Pechner - 2004-02-24

    Logged In: YES
    user_id=385376

    For CVSMonitor/Bankend/CCVS.pm, you meant add "Branches"
    to USABLE_VERSION_KEYS not USABLE_FILE_KEYS.

    At line 119:
    # Trim off any object keys we don't need
    foreach ( keys %$Version ) {
    delete $Version->{$_} unless
    $USABLE_VERSION_KEYS{$_};
    }

     
  • Adam Kennedy

    Adam Kennedy - 2004-02-24

    Logged In: YES
    user_id=153576

    My normal method is to use the perl debugging through cvsexec.pl

    So for example...

    fission:/home/adam/ali.as/cgi-bin/demo/beta/cvsmonitor$ perl
    -d cvsexec.pl update Alias.OpenSource
    Default die handler restored.

    Loading DB routines from perl5db.pl version 1.07
    Editor support available.

    Enter h or `h h' for help, or `man perldebug' for more help.

    main::(cvsexec.pl:24): require 5.005;
    DB<1> b CVSMonitor::Backend::CCVS::File_new
    DB<2> c
    CVSMonitor::Backend::CCVS::File_new(modules/CVSMonitor/Backend/CCVS.pm:204):
    204: my $class = shift;
    DB<2> n
    CVSMonitor::Backend::CCVS::File_new(modules/CVSMonitor/Backend/CCVS.pm:205):
    205: my @source = isa( $_[0], 'ARRAY' ) ?
    @{shift()} : return undef;
    DB<2> n
    CVSMonitor::Backend::CCVS::File_new(modules/CVSMonitor/Backend/CCVS.pm:205):
    205: my @source = isa( $_[0], 'ARRAY' ) ?
    @{shift()} : return undef;
    DB<2>

    And from there you can use the 'x' command to view an
    expression...

    DB<3> x @source
    0 ''
    1 'RCS file:
    /var/lib/cvs/CPAN/Templates/Attic/Application.dwt,v'
    2 'Working file: Templates/Application.dwt'
    3 'head: 1.17'
    4 'branch:'
    5 'locks: strict'
    6 'access list:'
    7 'symbolic names:'
    8 'keyword substitution: kv'
    9 "total revisions: 17;\cIselected revisions: 17"
    10 'description:'
    11 '----------------------------'
    12 'revision 1.17'
    13 'date: 2002/11/20 17:15:41; author: adam; state: dead;
    lines: +0 -0'
    14 'Completed the primary reskinning work'
    15 '----------------------------'
    16 'revision 1.16'
    17 'date: 2002/11/04 21:32:07; author: adam; state: Exp;
    lines: +1 -1'
    18 'Updating Templates so that people understand they
    won\'t get all the features visible in the ali.as demo'
    19 '----------------------------'
    20 'revision 1.15'
    21 'date: 2002/11/02 00:26:45; author: adam; state: Exp;
    lines:

    etc etc

    The reason I suggested using a very small seperate module is
    basically because these 'views' can get very VERY large

     
  • Adam Kennedy

    Adam Kennedy - 2004-02-24

    Logged In: YES
    user_id=153576

    Yes, I probably did mean USABLE_VERSION_KEYS, although if
    you notice in my previous comment, there is

    4 'branch:'

    Although I forget exactly what information is in it...

     
  • Michael Pechner

    Michael Pechner - 2004-03-03

    Logged In: YES
    user_id=385376

    I've been spending time in the last week to read the code.
    When do you use cvsexec.pl versus calling CVS directly.

    Is there a reason why you did not fully encapsulate all the
    CVs calls?

    For the most part I like teh way you wrote the code.

    Although I tried to use optiperl to dig through the code. Your
    use of autoload makes optiperl not very usable.

     
  • Adam Kennedy

    Adam Kennedy - 2004-03-04

    Logged In: YES
    user_id=153576

    The use of cvsexec.pl allows the admin requests, which can
    take a very long time, to be backgrounded.

    That is, we call

    cvsexec.pl command &

    Otherwise, the very long lived CVS processes cause the
    browser to time out.

    The Class::Autouse autoloading functionality can be turned
    off via

    use Class::Autouse ':devel';

    In fact, if you turn on the main $DEBUG global in
    cvsmonitor.pl, it will do this for you.

     
  • Michael Pechner

    Michael Pechner - 2004-03-15

    Logged In: YES
    user_id=385376

    Next dumb question. How do you want me to submit the changes
    to the files.

    The changes are to CCVS.pm and File.pm.
    CCVS.pm I made the siggested change.
    File.pm I added 2 methods. of getBranches(), returns an
    array of branch revisions. i.e. the keys of branches element.

    getBranch returns the version for the passed in revision.

    the one short comming will be where we want the branches for
    all the files at the head of a branch. After all first goal
    was to see the graph and changelogs for a specific branch.

    So let me know what's next. and how to submit my changes to you.

     

Log in to post a comment.