Re: [alf-dev] RE: ALF Source Code Mangement Vocabulary Meeting+1-303-928

[Eric Minick <etm@xxxxxxxxxxxxx>]

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
>