On Thu, 2006-11-16 at 12:36 +0000, Phyrefly wrote:
> This seems to be the one point everyone is not getting, or ignoring,
> by showing, in some cases, very complex solutions to the use cases I
> am suggesting would be made easier by labels.
I think you are approaching this from the wrong angle. Branches
are the 'subversion' way of doing things and replacing them
probably isn't going to happen. On the other hand, there are
some things that awkward to do with branches that perhaps
could be made easier. Why not go through a use case and propose
changes in branch/merge handling that would help with the
problem. That will then help both the case where a name for
a revision would work and also the ones where you really
do need the branch (that is, you need things in there that
you don't ever want to appear on the trunk).
> >
> > It's not always a marble if it's round, only if you would play like you
> > would with a marble.
>
> It's a branch if it's implemented like a branch. Because it's
> possible to treat it like a branch (commit further revisions, etc) - I
> have to configure more things to stop it being used as one.
I'm not sure it is subversion's job to prevent your users from doing
something you don't like. Can you concentrate on letting them do
the operations that need to be done? That is, if using a branch
is a problem, how can a branch be made less of a problem?
> It's a
> hack, basically, to make a branch feel a little like a label... in the
> implementation, it's a branch, with everything that implies. But most
> importantly, it's NOT just a link to a prior revision, it's a copy of
> that revision in another place in the repo, meaning that it loses some
> of the flexibility that a label would have.
If what you want is just
myname=351
where 351 is a repository revision number, put that in a file committed
to the head of the trunk where you can always find the current copy.
Grab it through the web interface if you don't want the trappings of
a head checkout just to read it.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 19:12:57 2006