Please reply to the list...
>> -----Original Message-----
>> From: Phyrefly [mailto:email@example.com]
>> Sent: Tuesday, November 28, 2006 2:40 PM
>> To: L. Wayne Johnson
>> Subject: Re: RE: Re: Simple Label=RevisionID Discussion
>> > It seems the real argument here is "It's too hard for me to -- type in
>> > long URLS for, remember where to find, figure out what the names are --
>> > my labels so I am going to just check everything out and search for it
>> > locally. It probably is too hard for some people. That's why subversion
>> > offers ways to augment its base functionality using: C, C++, Ruby,
>> > Perl, .... Of course it not easy or it would have already been done.
>> So your answer to "The current functionality is too complex" is:
>> "Their are even more complex ways to create your own expansion to
>> existing functionality"? And you can't see the logical problem with
>> this "solution"?
NO, are you intentionally missing the point? It seems some would like
subversion to be all things to all people. A story about a man, his son and
donkey comes to mind...
If the current solution is too complex then which steps do you wish to
eliminate? Or is it that you wish to hide the complexity with a simple
My impression is that you wish to hide the complexity with a simplified
interface. This means someone has to do some work. Clearly you want someone
else to do it for you. There is nothing wrong but don't complain when people
don't do it for you fast enough.
>> > <The follow is a comment on the entire thread and NOT this particular
>> > Except for the "it's too hard" arguments listed above, I still do not
>> > understand how a tag is not a label. Oh yeah, you have to install a
>> > script to keep people from turning them into branches...
>> It is not _just_ a name for an important revision. It is a separate
>> copy of a working copy at a specific time. Exactly what subversion
>> exists to stop you having to do.
Other than "but I have to install a hook script" or "but the URLs are too
<put your complaint here>" I still don't understand what you can't do with a
copy that you can do with a tag.
Okay, you can't pick arbitrary revisions of files without a bunch of work. I
am not sure how a label is going to help here since subversion does not
track individual files, it tracks projects. You would still have to go
through and hand-pick all the files. Once that is done you could create a
>> > I don't mean to be offensive but some of this thread just seems silly
>> to me.
>> Me too. I think it's exceptionally silly that some people can't
>> understand that tags are just beyond some users. I think it's even
>> more silly that some people can't understand the difference.
This is exactly the point. There are just too many opinions about what the
right way is. Subversion can either tell you what the right way is (which I
am sure you would not agree with) or they can provide you with a tool that
is flexible enough to do it your way. Flexibility means that you must do
more work (or find some developers creating a version control tool that
agree with what you believe to be the right way.)
This is not to say that there aren't issues with subversion. The developers
are currently working on some key issues: merge tracking, renaming, etc. I
believe that at least some of these features would be requirements for what
you would really like to do.
>> > Someday will have software complex enough to figure out what I meant to
>> > Until then I am going to have to be explicite.
>> Or have software that actually has different implementations for
>> different pieces of functionality. Branches, tags and labels are all
>> different things. Why have they been implemented in identical ways,
>> and the differentiating functionality been left to the user to add?
>> Subversion does not have tagging or labelling functionality built into
>> it. It only has branches, and the rest is up to the user to figure
>> out, through permissioning, hooks, or expanding functionality. How
>> can you say that nothing more is necessary?
Who said nothing more is necessary. If that was the case then there would be
no need to provide the ability to extend subversion via C++, C, Perl, Ruby,
Python, etc. Clearly your view of what version control should look like
differs from what the core developers believe. Why aren't you glad they
decided to allow flexibility instead of imposing their own view?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 29 01:29:20 2006