> Yes, but the joy of SVN is that we don't have to search through any
> printed out hard copies. Having real-world, hard-copy parallels
> doesn't make the SVN implementation easier or more sensible,
>
> What you're saying is that although I keep my monthly bank statements
> in a drawer to the left of my desk, in a nice neat stack, in order to
> keep my yearl-end ones accessible, I must photocopy them and put the
> copies in the drawer to my right, because I don't HAVE a post-it to
> stick on the side that would allow me to lift the year-end statement
> straight out of the stack. This means that I have a different
> work-flow to find my year-end statements to my monthly ones, and that
> I have used up a second drawer for no reason.
Well... You've got a point there too.
> See, parallels can be written either way far too easily.
Yep you're right. Well can't blame me for trying ;)
> Nope, that's not how "mutable labels" were defined when someone coined
> the phrase earlier in this thread. The term was used to define moving
> the label from one revision to another, not changing the code in that
> revision. The latter is a branch, and should always be treated as
> one. The code in a "label" could never be edited, as a label is just
> a pointer to a rev, not a copy of it that could be edited.
>
> No, I said not JUST an earlier revision. It's a COPY of that earlier
> recision, with its own potential for history, and in a different
> location.
So, in fact your main reasons for not acknowledging a copy as label is:
* You can't insert an alias as revision number.
* It has it's own history, and thus (I guess you don't really mind the
history, just the fact that you can do more than just point to existing
files and revisions)
* It can potentially be used for branching purposes by modifying the
"label"-contents and therefore it can not be a label.
The latter one is important isn't it?
Do you have any additional arguments to add?
I'm actually fishing for arguments because there've been some
discussions before (you probably guessed) and one of the discussion
actually progressed into discussing solutions instead of the problems.
(NOFI, it's just a difficult subject :D)
One of the most interesting solutions was creating a wrapper around
subversion (cross platform ofcourse) for managing "projects" and it's
labels and branches.
By using this script we can "convert" tagnames into locations without
the user even knowing. Also it should be possible to manipulate labels
like you would in CVS (and possibly other like CVS).
I.e. if we could limit the possible operations to 'copy' and 'delete'
and they would be done "underground" it would seem to be the same like
original labels. (And with history so you can look back at changes in a
label.)
> At least this is a new set of questions :)
Had to get the "feeling" :P
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 21:59:27 2006