> No one is arguing that symbolic names are not more friendly, the question
> is how best to implement them, if at all, while maintaining many of the
> "tenants" upon which svn is based. Where would this file go? How would
> it get to the clients? Those are the specific questions I talked about
> later on in the past email message.
> Also, I believe from past messages, many people have pointed out that you
> can accomplish many of these "symbolic" references in your command line
> shell if that is what you want. Simply define a variable named
> "Release1.0" that defines the URL of the tag. Then reference the variable
> in your command line in place of the URL.
>> > See, now this is the real issue. It is a legitimate request and has
>> > mentioned before. Someone just needs to come up with a clever way to
>> > implement it. I suspect that the first thing we need is the idea of
>> > central configuration properties that are hosted in the repository.
>> > this problem is solved, it should be possible to build on top of that.
>> > example, perhaps you could define aliases that refer to URL's and then
>> > those aliases in the commands.
>> Fair enough. Wouldn't some (additional) structure enforced in the
>> repo help? All programs have rules -- even in the Unix/Linux "wild
>> and willy anything goes survival of the fittest" atmosphere. Having
>> trunk, branches, and tags required would make your aforementioned
>> clever implementation easy?
> I don't think so, I think it would be a terrible idea. I do not know how
> new you are to this list, but just this week there have been several
> different threads about repository layout for documentation. Those people
> did not want trunk and branches folders, why force them? I am not sure
> that it would make it that much easier to implement symbolic names anyway.
I guess I don't understand.
If every child subdirectory of tags represents a static tag and
if every child subdirectory of branches represents a branch tag,
wouldn't it be easy?
subdirectory name = tag name. Done.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Sep 23 20:57:37 2004