the importance of inventories

[Sander Striker]

> From: changesets-admin at sp.red-bean.com
> [mailto:changesets-admin at sp.red-bean.com]On Behalf Of Tom Lord
> Sent: Tuesday, April 15, 2003 8:51 PM

>     me:
> 
>     >> That's an important usage case for even SCM tool designers to
>     >> consider:  I export a tree as a source distribution from my SCM
>     >> repository to a tar bundle.   Joe picks it up and installs it
>     >> somewhere.  
> 
> 
>     > From: "Sander Striker" <striker at apache.org>
> 
>     > Ok, so where are his inventory tags then?  He installed from a
>     > source ball, plain source, no add-ons.
> 
> More precisely, whatever add-ons are there to record inventory tags
> should be easy to manipulate with few special purpose tools and able
> to be imported and exported usefully from various source control
> regimens.
> 
> We're presuming here that Joe has installed a copy of the programs for
> generating and applying changesets.

Urf.  You really have the vision that software releases are going to
be carrying this information in a forseeable future?

> It's reasonable to say that, along with those, he gets some tools for
> managing inventory tags -- but with the qualification that such tools
> should be small, simple, and not tied to a particular SCM system.

...

>  (As should be the changeset tools generally).

I'm afraid we have a total different view of the world.  Yours seems
to be a lot more optimistic than mine.
 
> Where inventory tags are in-play, arch currently uses two mechanisms,
> as you are probably aware:  implicit tags stored in comments in source
> files, and explicit tags stored in .arch-ids subdirectories (for
> tagging directories themselves, binary files and other files that you
> don't want to carry implicit tags, and symbolic links).

Great, multiple mechanisms that accomplish the same.  Why not use
external tags all around?  Please don't tell me it is so that mv
will work without thinking about it.

> In arch terms -- I'm talking about factoring out the arch commands
> `add', `delete', `move', `inventory', and `tree-lint' -- and making
> such modifications to those commands as is desirable to make them 
> palatable to other SCM systems.
> 
> Factoring those commands out of arch is no big deal.   They are not
> layered on other elements of arch.
>
> An interesting question, imo, is whether or not those mechanisms can
> be put to good use within svn (as I suspect they can).

Feel free to demonstrate.  [and I mean demonstrate, not suggest].

>     >> Later on:  Joe might have modified his tree.   I, meanwhile, need to
>     >> extract a changeset from my SCM world to send to Joe, who is going to
>     >> apply it without access to my repository.
> 
>     > In other words, a patch against a certain revision (the one that was
>     > called a release and packaged in a tarball which Joe picked up, etc).
> 
> Right ... although the tree that Joe has may no longer be identical to
> that release.

He started with that release.  Chances are that Joe just wants to send all
his changes wrt

> If we impose intermediate parties on the chain of
> possession leading up to Joe --- he may very well not have access to
> the release.

He may not have access to the release?!  Where did he install from then (given
your example)?  And if he doesn't have access to the release he also won't
have access to said inventory tags... The scenario you're portraying is very
unlikely (IMHO).
 
>     > > So he needs inventory tags.
> 
>     > And how is that going to work when he doesn't start with inventory
>     > tags in the first place?
> ?
> 
> To be more explicit: in order to design changesets, some notion of
> logical file identity that is independent of any repository or SCM
> system is needed.   So there's a big hard problem of designing SCM
> problems -- but there's a smaller and separable problem of design
> logical file identity as part of designing changesets.   A reasonable
> way (the only way I see) to design logical file identity is to define
> it as a set of conventions for the layout and content of source trees
> and source files.   So when Joe gets his tar bundle, that tar bundle
> includes tags.

If that is what your aim is, yes, then you need something like logical
file ids (which need to be shipped with releases etc).  Personally I
don't feel like designing/implementing this all.  And therefor I feel I
have nothing to contribute to this list anymore if this is going to be
the goal.

>     > > There's countless variations on that scenario.  (E.g., perhaps Joe is
>     > > comparing two trees and sending me back a changeset.)
> 
>     > Ah, a patch against a certain revision...
> 
> Not "revision" in the SCM sense.   There's no reason to presume that
> the two trees Joe is comparing have any identity in an SCM namespace.

Might aswell just stop here, since we are just talking about different things
with different things in mind.

[...]
>     >> Part of the goal here is to work on standards for interoperability.
> 
>     > Lets start with a _simple_ tree patch format.  And a simple
>     > implementation that can generate/apply those.
> 
>     > Currently I get the feeling this list is aiming to implement a
>     > full-fledged changeset engine...
> 
> Arch's mkpatch/dopatch have a simple format and implementation.  It
> needs things like syntax changes but that's pretty superficial.
> 
> Arch's mkpatch/dopatch are factorable away from arch.   They depend on
> almost nothing else in arch -- not in any serious way.

So basically, you just need to start coding ;).


Sander