Doug,
Thanks for the comments!
In the Objects write-up (section 3 of the
Wiki document), I may not have been as explicit about this as I should have
been, but the “owner” of a Version object should be the person who
created the version (i.e. did the checkin that created the version). This could
be different from the owner of the element and file, as you point out. Thus if
you can get to a set of Version objects that were part of a change-set, you can
query them for their owners to see who made the changes.
I think this matches the ClearCase model
(a version’s owner is the person who did the checkin).
[Side note related to this: AccuRev has a
feature called “annotate”: If you say “annotate file”
it displays the file line-by-line, showing who created each line. Some people
have jokingly suggested the feature should be renamed to “blame”. J ]
On activity-based SCM: I had in mind that
our “change-set” concept corresponds to ClearCase’s notion of
an Activity. (In fact I mentioned that in the Wiki where I said “UCM
ClearCase: Activity” under synonyms for “change-set”). A
change-set [activity] can be associated with an issue (or defect/task/whatever)
and then the change-set can be used as short-hand for the set of changes in it.
Cheers,
Richard Title
From: alf-dev-bounces@xxxxxxxxxxx
[mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Doug Fierro
Sent: Thursday, May 18, 2006 1:57
PM
To: alf-dev@xxxxxxxxxxx
Subject: [alf-dev] RE: ALF Source
Code Mangement Vocabulary Meeting
Hello,
Sorry I have not been able to contribute much to the vocabulary efforts to date
due to some major changes at our company this quarter :-) I have primarily
participated on the ALF requirements committee since last year, but
representing a build vendor I wanted to contribute my feedback on this thread.
I reviewed the use cases outlined below and overall I think it covers most of
the typical use cases as build relates to interacting with SCM. Good work so
far.
I have the following feedback-
I don't see a use case for querying the SCM system to determine who checked in
the version of a file used for a build. I believe CruiseControl is one example
of a build tool that has this ability, which is used to send the
"owner" of a file or set of files an email if a build fails. I know
in some SCM systems like ClearCase, the concept of a "owner" of a
file or element is different from the person who checked in a particular
version of a file, while others may not have this distinction.
The other note/question I had is, are we going to have use cases that support
activity-based SCM? That is the direction the industry is going with regards to
SCM. I think most of the commercial SCM tools support the idea of having a high
level task, issue, activity, etc. representing one or more individual files to
accomplish the task. This may affect use case #7, "Produce Difference
Report", where the difference report can contain not only the files that
differ between two builds, but the incremental activities/tasks/issues etc as
well. The same with use case #8, "Produce Bill Of Materials Report".
And a question along this line regarding UC#3, "Get New Versions
Since" - by date and baseline are listed as examples. Would this use case
also cover getting new versions by specified activity as well? The use case for
this is a build team only wants to get the incremental source to build on a
project for say a select number of issues , defects, or enhancements but
nothing else.
What we call these higher level abstractions the team can decide- the industry
ranges from defects, bugs, requests, enhancement requests, ECOs, tasks,
activities, change packages, issues, ticket, PR, MR, etc. I don't think there
is an agreed SCM industry term on this. I think using a general term would be a
good idea that can cover as wide a variety as possible.
I think when defect tracking use cases for bulid systems get addressed later,
some of this will no doubt overlap. But for many companies, their SCM and
tracking solutions are one in the same, and they would expect to manipulate and
report on these abstracted tasks through the SCM interface or service made
available.
The first use case title to me is not intuitive, "Get a project/component
that needs to be built". I think "creating a workspace" better
describes what is being done, and better flows going into UC#2, "Update a
workspace".
Something to think about is promotion within the SCM system as a result of the
build. A use case is promoting a baseline within the SCM system if it builds
successfully; similar use case for promoting a set of activities as well. If
some groups initiate this from the SCM tool, then the idea is that ALF can
trigger a pass/fail event for the build request, and the SCM tool can
appropriately process it. Do we want to consider a use case where this is
instead initiated from the build tool as well?
I don't see a use case for cleaning up or removing a build workspace. These are
considered transitory work areas, and anything that needs to be persistently
stored or preserved beyond the build would be checked in or saved in some
defined repository. You don't want to have your build server accumulate a bunch
of workspaces over time. While some build teams may prefer to keep a build
workspace around for some period of time, which makes sense for viewing build
results, troubleshooting, etc., others may want certain types of builds cleaned
up immediately I imagine.
Doug Fierro
Director of Product Management
Buildforge / IBM Rational Software
dfierro@xxxxxxxxxx
512 225 0436
http://www.buildforge.com
>====================================
>From:
alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
>On Behalf Of Eric Minick
>Sent: Tuesday, May 16, 2006 3:16 PM
>To: ALF Developer
Mailing List
>Subject: Re: [alf-dev] RE: ALF Source Code
Mangement Vocabulary Meeting
>meetingminutes
>
>SCM Vocab Team and all,
>
>I've put together a quick overview of the SCM
integration use cases from
>the perspective of build management tools.
Comments and suggestions from
>those who are familar with these tools would
be most welcome.
>
>It's currently up on the wiki here:
>http://wiki.eclipse.org/index.php/ALF/Build_Server_Use_Case
.
>
>As we discussed, this is a fairly coarse
grained set of use cases. On
>further reflection though, I'm not sure that's
the right direction. As
>we move have added more customizable workflow oriented
behavior in our
>commercial app, we found it helpful to expose
more low level and scm
>dependent concepts directly to the user -
particularly the advanced
>user. In the open source tool, the coarse
grained approach does simplify
>development.
>
>In a tool like ALF that is primarily geared
towards users scripting
>interactions in service flows, finer grained
use cases might be more
>appropriate, if only in the context of the
more coarse.
>
>Cheers,
>
>Eric Minick
>Urbancode, Inc.
>_______________________________________________
>alf-dev mailing list
>alf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/alf-dev
