Re: [DESIGN] Aliases? (Was: RE: Re: I, too, miss tags.)

On Sunday 26 February 2006 21:05, Rob van Oostrum wrote:

> I think you're vastly oversimplifying the wrapper solution if you think
> it'll easily resolve your issues.

Hmmm... I tend to think that in our implementation of label lists it should be
simple. Your suggestion to use tree traversal seems like overcomplication,
but if we do not go for it, it remains small and will require only local
access to one dir.

But the best is to try to implement it, and we will see . I think I and others
can do a test version rather quickly and see how it behaves.

> Also, if this is to be adopted by the SVN community, it makes no sense
> whatsoever to implement it as a 'simple' wrapper.

A wrapper would be a first prototype. It would also be mostly adequate for my
needs since I work mostly from CLI.

> It will also need to
> support a lot more scenarios than what I think you've thought through so
> far.

It would be nice if you listed those scenarios that we miss, and we will see
if and how they can be accommodated in label mechanism.

> It will also need to be *supported* by the SVN community once it makes its
> way into a general release of SVN.

Sure. Thats why the discussion in the list happens. I could have written that
damn wrapper long ago instead of chatting in the list, but I seems to make
sence to join efforts, at least of those who want label functionality, and to
coordinate this at least slightly with Subversion developers.

> As a result, the developers that make up
> the core group have a vested interest in making sure that what's adopted
> into the code base is going to be worth *their* time.

Hmmm....

> I don't think any of these discussions have met that burden, especially not
> considering that SVN does contain functionality to help you do what you're
> ultimately trying to do (i.e. store an 'alias' for a particular revision of
> a particular URL). Your only issue is that it's not the type of solution
> you prefer.

AFAIU, functionality that Subversion offers was already in CVS, still the team
has started a new project -- to make version control "the way they prefer".

As I have noted already, existing functionality is not everything. You also
need convenient access to that functionality, and this is what good software
is about, from the user's perspective.

> I think ultimately what you're looking for does not have a place in SVN
> itself.

It is a pity to hear this, since the most of the peaces (revision numbers,
properties) are already present in svn, and one needs a small tie of the
functionality.

> That does not mean it might not have added value if executed on
> properly.

This sounds encouraging ;)

This is the way to go. We write a wrapper script and see how it behaves. If a
good consensus will be found, the script may have further adoption.

It would be nice however that at least to same extent the efforts are
coordinated. E.g., it would be nice to know that the property name, whatever
we choose for storing labels, is not used for something else in the next
release of Subversion...

> Ultimately, opensource projects are run by those who do the work.

Sure.

> If you feel strongly enough about this and you can't get anyone else to
> contribute their time, do the work yourself. At the end of the day, it may
> or may not be accepted into a general of SVN.

This sounds encouraging and motivating to work. It would be a pity to have a
useful peace of code rejected only on "philosophical" grounds.

> If it isn't, it's your code and you're
> free to share it with anyone so more may benefit.

Beyond doubt.

-- 
Dr. Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax:      (+370-5)-210 40 05
mobilus:      (+370-684)-49802, (+370-614)-36366
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org