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

Re: Is label support in future release?

From: Phyrefly <phyrefly.phyre_at_gmail.com>
Date: 2006-11-17 01:46:35 CET

> K, then look at it this way:
> I've made a copy of a document I'm sending to a company. I keep this
> copy in a special drawer where I keep all sent-in copies.
>
> When I use your approach, I'm going to go to the large pile of document
> print-outs (versions), searching through it to find the correct version
> (with a post-it note sticking to it, saying: "I sent this copy to the
> company").
>
> While my approach says: Go to the drawer with sent-in documents. Find
> the folder labeled with the document name and the company name and get it.
>
> Comparing it to a simple real life example, I find my approach more
> logical, don't you?

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.

See, parallels can be written either way far too easily.

> [[[ (This was when explaining why it's too much 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
> ]]]
>
> So here you say that labels shouldn't be changed. (= committing further
> revisions, which includes including files from different revisions, etc.)

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.

> >> Please!!! Name the flexibility I'm missing because I've created a copy
> >> instead of just a label. (I seriously can't think of any.)
> >
> > You can't feed it into an svn command instead of a rev number. It's
> > no longer just an "earlier copy" of the HEAD file, it's a _different
> > URL_ - and that's not a simple adjustment for a non-techy to make.
> So you tell me that if I make a copy of a document, and put it somewhere
> else, that the contents of the copy have changed?

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.

> > Seriously, I've not been asked a question that's had a different
> > answer since I chipped into this thread, ...
> Sorry, didn't mean it this way.

At least this is a new set of questions :)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 01:47:10 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.