[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [alf-dev] RE: ALF Source Code MangementVocabulary Meeting+1-303-928-3232id 6053141# Wednesday 10:00AM PDT - meeting minutes
|
For an integrator, what you get back when you ask for changes between to
a workspace and a past incarnation thereof is already pretty arbitrary
between tools already. I think we'll want to layout a pretty flexible
format and just take what we can get from the various tools. The change
log will look different based on the tool used.
That's ok because it represents what actual change happened in the
system. You don't want CVS to pretend that a delete followed by an add
was a rename.
-- Eric
Richard Title wrote:
You may be right. Certainly for an individual command like "rename foo fum"
or "move src/foo bar/foo", it's not too hard to see how to translate that
into equivalent directory operations, if that's what ClearCase needs to do
internally. A more interesting case is a command like "show me all the
differences between branch B1 and branch B2". If ClearCase thinks of
rename's and move's as directory differences, does it have to translate
those into the equivalent file-name/file-parent differences?
Then again, who cares about ClearCase? [I didn't actually say that... :-) ]
Cheers,
Richard
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Eric Minick
Sent: Wednesday, May 03, 2006 4:49 PM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] RE: ALF Source Code MangementVocabulary
Meeting+1-303-928-3232id 6053141# Wednesday 10:00AM PDT - meeting minutes
Richard,
I may just be showing my ignorance of scm systems, but I'm not sure the
namespace-handling should be that tough. The integrating tool will be
working on a workspace and either it, ALF or both will know the
configuration for that workspace. Given a configuration, an ALF command
could simply say, "rename /myproject/source/data.c
/myproject/source/useful_data.c" perhaps with an element id.
From there it's up to the tool's ALF integration job to worry about
what happens. In subversion the operation is on the file; in Clearcase
it's on the directory; and in CVS you delete the old file and make a new
one. Why should ALF care?
My other thought, and I suppose this is obvious, would be that we may
need a command that asks the SCM integration, "What do you support?" Or,
"How do you work?". From there we can get into interesting things like
meta-data.
But other things are more basic. If I want a fresh copy of Project X, in
our use cases one would:
1) Create the workspace
2) Matterialize the workspace
That's fine in a lot of systems, but in CVS creating the workspace (cvs
checkout) implicitly populates it as well. Step 2 could be skipped. ALF
will need to know that.
A sub use case of diffing a workspace would be to just ask, "are there
any changes to this workspace?". Going back to CVS, getting a full
revision listing can be an expensive operation. Some versions (and only
some) of CVS have a seperate command for "are there changes?" that would
save a workflow time if there are not. Right now, integrating tools
either ignore this or solve it with a check box. Other tools are in a
similar boat. Last time I used Dimensions (feel free to correct me) from
the command line it was pretty easy to get a list of the last time each
file had changed. So figuring out if anything had changed since some
date was easy. But to get the details of those changes was considerably
more expensive.
I suspect that as we go, we'll hit more situations where some tools have
combined two concepts that ALF might otherwise assume are atomic. One
option is to have them report their behavior. The other is to make ALF
use cases at a larger grain. If instead of:
1) Create a workspace
2) Materialize a workspace
We had:
1) Create and populate a workspace.
2) Update a workspace (re-materialize)
ALF would need to know much less about the SCMs it was integrating with,
but they would be more likely to operate in a sub-optimal way. Both
approaches work fine.
I've rambled quite long enough. Sorry about that.
-- Eric
Richard Title wrote:
...
We ran out of time at the end to discuss some of these, but Brian Carroll
included managing metadata as a possible use case. I could see Subversion
users potentially wanting this feature as metadata can be used for a
variety of purposes. In Subversion metadata is associated with a file or
folder and can be essentially anything including binary content, such as
thumbnail image for a JPEG.
Agreed. I had in mind use case 7 (create new version of Element) as
potentially covering changes in the data (i.e. the file-content), and/or
changes in the metadata (a.k.a. properties, a.k.a. attributes) of the
Element. Metadata could include filename, parent directory, modification
time, owner, permissions, file-type, thumbnail-image, etc. See Concepts,
item 2 (File & Directory concepts).
The part that can get thorny is namespace-handling. Is renaming a element
an
operation on the element itself (as AccuRev does), or on the directory
containing it (as ClearCase does)? Is moving a file to a new directory an
operation on the element being moved (AccuRev), or on the parent
directories
involved (ClearCase)? What's Subversion's model?
Richard
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev