--- Brian Huddleston <brianh@huddleston.net> wrote:
> Since this seems to be a part of a general argument
> pattern. I thought I
> would respond.
Thanks. I think you summed up what I am looking for
quite exactly and better than I could by using the
example of the tools.
I currently use TSVN as the access to SVN, and don't
have a need to go to the command-line at the moment.
(May be I will in the future as I get into more Unix
development, but currently I am only developing on
Windows.)
In order to do my tags for releases, I have to (a)
create a tree under my URL/tag branch, and (b)
branch/tag to it. When I check out the tag, I then
have to remember to (a) go to URL/tag/TAGNAME/trunk,
and (b) export to my local system.
I do this specifically because I want to mark a
specific release of the source at a specific revision
for use as a specific purpose (e.g. Beta_Candidate_1).
I would much rather be able to just export a revision
called 'Beta_Candidate_1' than have to remember these
extra little quirks (e.g. going to TAGNAME/trunk). As
was said below, specifying the revision name -
Beta_Candidate_1 - would be a lot simpler, and I would
know right where to put it - in place of the revision
number.
Any how...I think Brian summed it up quite well with
his example. Just 2 cents to add to it with a little
more specific implementation of the example.
BRM
> ----- Original Message -----
> From: "Richard Lewis" <rtf@jabble.com>
> To: <users@subversion.tigris.org>
> Sent: Sunday, May 08, 2005 6:20 AM
> Subject: Re: Mnemomic names for revisions
>
>
> > David Weintraub <qazwart@gmail.com> writes:
> >
> >> 3). We want to be able to create labels, do
> diffs, etc., without
> >> having to bother with URLs Doing "svn diff
> -rFOO:BAR myfile.cc" is a
> >> heck of a lot easier than:
> >>
> >> svn diff
>
http://myserver/repos/tags/FOO/dir1/dir2/dir3/myfile.cc
> >>
>
http://myserver/repos/tags/BAR/dir1/dir2/dir3/myfile.cc
> >
> > export FOO=http://myserver/repos/tags/FOO
> > export BAR=http://myserver/repos/tags/BAR
> >
> > svn diff $FOO/myfile.cc $BAR/myfile.cc
>
> Repeat as necessary for each tag in your repository.
> Mine has 2558 at
> present. :-) Then write a nice hook script to push
> the new list of tags out
> to all the client machines (we do know them all
> right?) so that everyone can
> be consistent.
>
> The above also assumes that you're on a unix box
> (you can also do it under
> Windows, but it much clunkier) and that you're using
> the command line tools.
>
> If "labels" or "mnemonic names" is not a first class
> citizen, then there
> isn't going to be any support for it in the tools.
> I can't expect
> TortoiseSVN, viewcvs, joe random web viewer,
> subclipse to support my random
> hack to simulate more traditional tag functionality.
> Heck, with one
> exception, none of the tools even let you diff
> tags/R5_3_3456 with
> tags/R5_4_3455 despite the fact there is command
> line support for it.
>
> Given the fact that the tags/ directory itself is
> pure convetion I guess
> that isn't too surprising. Writing a nice easy to
> use GUI that diffs
> arbitrary directory 1 to arbitrary directory 2 is
> probably difficult at
> best.
>
> At my shop even the developers rarely drop to the
> command line. I do, of
> course, but I am the exception rather than the rule.
>
> All the tools, though, let you type in a revision ID
> to get a diff. People
> just want to be able to type Beta_1 and Beta_2 into
> the two boxes instead of
> 23422 and 23942.
>
> (Well, I take that back, nearly everyone wants at
> least *that* I think,
> after that point opinions diverge greatly. :-)
>
> >> 4). Labels should be first class citizens.
> Creating a directory to
> >> represent a label is really a hack -- especially
> since you need a
> >> (so-far unpublished) hook to prevent someone from
> accidently changing
> >> what a tag points to in order to do this job
> correctly.
> >>
> >
> > But you'd also need a way to change which revision
> your label refers
> > to, and hence a way to prevent someone changing
> your label... (surely
> > if you can't trust your users to leave the tags
> alone you've got more
> > problems than adding labels to subversion will
> support?)
>
> Not necessarily. I think a majority of people
> simply want a map 29845 to
> something more meaningful like R5_build_4.
> Revisions are immutable.
> Branches-called-tags are not. It isn't about trust
> or preventing malicious
> behavior its about preventing accidents. Unless
> you're a small enough shop
> that someone is watching every commit, or a large
> enough shop to afford to
> have someone dedicate their time to watching "tag"
> commits you're stuck with
> doing a hook-script.
>
> The hook script is doable, certainly, that's how
> we're setup, but it strikes
> many people with a traditional SCM background as a
> bit of a hack to have to
> write a script to enforce a semantic which they
> believe to be inherent to
> the idea of a tag.
>
> >>
> >> =====
> >> I think that the arguments made by the pro-label
> side for arguments 3
> >> & 4 are quite reasonable. Having to use a full
> URL just to do a diff
> >> can be a problem.
> >
> > I see why labels are useful, but I dont understand
> why you don't just
> > write a shell script to do all this using
> properties (ie store the
> > labels in property on the repository root, and get
> the labels using
> > propget)
>
> Slow would be the primary argument. Lots of custom
> code would be the other.
> There is no svn speak to this point, for "Give me
> all the files that have a
> propery named foo that is set equal to bar.
>
> The argument about tool support also holds. Even
> assuming support for a
> label querying, the labelling idea is a hack that
> shop X put together to get
> the semantics they wanted and none of the tools are
> going to let them see
> the difference between Release_1 and Release_2.
>
> If you've got the staff and the time to write the
> tools yourself, then
> you're always fine, but if you don't you're out of
> luck.
>
> >> 3). Have an "svn label" command as an alias of
> the "svn copy". Well,
> >> not quite an alias, but more of a shortcut:
> >>
> >> $ svn label FOO
> >>
> >> would be translated to
> >>
> >> $ svn copy <current URL> <URL>/tags/<path>
> >>
> >> or whatever is needed to actually create the tag
> directory.
> >>
> >> Sounds good?
> >
> > isn't this trivial to do by hand (eg as a shell
> script)?
>
> Yes. Ideally, though, this would be a first class
> citizen and would have a
> separate identity in the history. It could also
> keep people who thought
> they were tagging, but typo'd the url from dumping
> stuff in the wrong
> directory. Yes, as goes the oft repeated argument,
> "This is version
> control. Just undo it.", but if it is simple for
> the tool to keep you from
> doing something stupid then the tool should help
> keep you from doing
> something stupid. :-)
>
> That is, my ever so humble opinion at least. Do
> with it what you may.
>
> -Brian
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail:
> users-help@subversion.tigris.org
> >
> >
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail:
> users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 9 19:57:30 2005