[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Rob van Oostrum <rob.vanoostrum_at_blastradius.com>
Date: 2006-02-26 20:05:08 CET

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

Also, if this is to be adopted by the SVN community, it makes no sense whatsoever to implement it as a 'simple' wrapper. It will also need to support a lot more scenarios than what I think you've thought through so far.

It will also need to be *supported* by the SVN community once it makes its way into a general release of SVN. 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.

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.

I think ultimately what you're looking for does not have a place in SVN itself. That does not mean it might not have added value if executed on properly. If you and other likeminded individuals want to pool your resources and come up with a solution that wraps around SVN, I would suggest you look at what the folks at SVK did: start your own project. Few would argue that SVK does not add value in certain scenarios. Few would argue that SVK should ever 'replace' SVN.

Ultimately, opensource projects are run by those who do the work. 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. If it isn't, it's your code and you're free to share it with anyone so more may benefit. Again, that's essentially what SVK is.

Cheers
Rob

> -----Original Message-----
> From: Saulius Grazulis [mailto:grazulis@akl.lt]
> Sent: Sunday, February 26, 2006 11:50 AM
> To: users@subversion.tigris.org
> Subject: Re: [DESIGN] Aliases? (Was: RE: Re: I, too, miss tags.)
>
> On Sunday 26 February 2006 18:07, Rob van Oostrum wrote:
>
> > IMHO, a system should also not try to be all things to all people.
>
> I agree.
>
> So, I believe there should be a consideration -- how much "code bloat"
> would
> labels introduce (I believe, little), how many people want/need them
> (judging
> from this ML, quite a few); how much effort would go into developing such
> functionality (no idea -- I did not hack Subversion source), who is going
> to
> do it (hmm... users who want it, right? ;), would such code be accepted
> into
> svn mainstream source once somebody does it (this is for the Subversion
> developers to decide).
>
> I think these points could be discussed here (possibly without repeating
> once
> more the "why you need this -- you can do svn cp etc etc...").
>
> At this point, a most rational solution I see to use a wrapper around the
> client, as some already did and as many others including me intended to
> do.
> This would be OK for Unix-like platforms and at least a proof-of-concept
> for
> Win. The best point in a wrapper is that it does not need any change in
> subversion itself.
>
> I guess all technical issues raised here regarding tags-as-labels can be
> easily resolved in a wrapper.
>
> --
> 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
Received on Sun Feb 26 20:03:27 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.