Branch should be captured with changeset
Brought to you by:
adamkennedy
Menu
▾
▴
#3 Branch should be captured with changeset
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. :)
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.
Logged In: YES
user_id=153576
Moving to feature requests
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.
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...
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?
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{$_};
}
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
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...
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.
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.
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.