You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Crucius, Wesley" <WC...@sandc.com> on 2004/03/23 19:54:13 UTC
RE: Thanks and a global versioning question; WAS:: Help: XML Pars
er e rror, Date Conversion failed
Hmm... Well, I think I see your point, but it seems to me that it would be
easier to "browse" a tree of tagged versions where the tag name matches the
release version identifier? In other words, a customer tells me he has
version V003R089 firmware running in his piece of equipment and has bug XYZ.
In order for me to debug the problem, I have to go get a copy of that code,
yet I don't have a revision-number-to-release-version cross-reference unless
I tag all released versions, right? I certainly don't want to use the
subversion revision number as my release version identifier, right?
Otherwise I'll have customers asking me (for example) why the revision
number has jumpped by a hundred or a thousand (due to changes to other
products in the repository) and I never called them to tell them that there
was a new version of firmware available during all that time... I probably
should have said this up front, but we do somewhat custom source coding for
embedded processors, so just about every customer that comes along gets a
new version in the baseline (trunk) or "branch" of an existing version. I
guess "svn log" gives me that cross-reference list, but then I have to
cut-paste or re-type to actually get a particular revision, right?
Am I all wet, or is this making sense?
Thanks,
Wes
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, March 23, 2004 1:34 PM
To: Crucius, Wesley
Cc: 'users@subversion.tigris.org'; 'Philip Martin'
Subject: Re: Thanks and a global versioning question; WAS:: Help: XML Parser
e rror, Date Conversion failed
On Tue, 2004-03-23 at 13:26, Crucius, Wesley wrote:
> On a side note, what do you think of the idea of a post commit script
> that automatically tags every commit? My proposed users aren't going
> to like (or
> understand) the global revision number so I'm hoping if I use a post
commit
> script to create a "YYYYMMDDHHMMSS" sort of a tag, they may never notice
the
> global revision number...
Trying to make your users use Subversion without noticing/using the global
revision numbers is like asking them to drive a car after removing the
tires.
Besides, every global revision already *has* a date attached to it... so I
don't understand how it would be useful to present your users with a
directory full of subdirectories named "YYYMMDDHHMMSS"? That would be
*less* confusing?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars er e rror, Date Conversion failed
Posted by McClain Looney <m...@loonsoft.com>.
your release identifier ideally would be the revision number. this is of
course different than the customer-visible "version" (2.0, 2000, XP etc).
in short, "version" is marketing & management. build # is for tech support.
by the way, microsoft does this too. see the various splash screens or
help/about screens on their applications. most contain a 64 digit (or so)
build identifier (including win* itself).
our applications always contain a hidden build stamp, which is the revision
built and the date/time in plain english. customers only see this if we show
it to them while troubleshooting.
On Tuesday 23 March 2004 01:54 pm, Crucius, Wesley wrote:
> Am I all wet, or is this making sense?
--
McClain Looney
LoonSoft LLC
m@loonsoft.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML
Pars er e rror, Date Conversion failed
Posted by Barry Scott <ba...@barrys-emacs.org>.
Is this useful feature planned? If this was in svn I think I'd never use
svn copy to tag a revision. It could also solve the problem of showing
which revisions on the trunk are interesting (have been tagged).
Barry
At 23-03-2004 20:44, Ben Collins-Sussman wrote:
>On Tue, 2004-03-23 at 14:40, Brad Appleton wrote:
>
> > - can I create a NAME property for a global revision number?
> > - does it make practical sense to implement a mechanism inside or
> > outside of SVN that simply maps revnames to revnums and vis-a-vis?
>
>Hi Brad!
>
>Yes, actually, you can attach any arbitrary properties you want to
>revision trees.
>
>
> > [ e.g., $(revname $(revnum $REVNAME)) eq $REVNAME ]
> >
> > $ svn commit --message "Corrected # of cheese slices."
> > Sending sandwich.txt
> > Transmitting file data .
> > Committed revision 3
> > $ myrevmap -revnum 3 -revname MyRevName
>
>Or, with today's svn, you'd just run
>
> $ svn propset -revprop -r3 revname MyRevName
>
>
> > Associated revision 3 of <??> with 'MyRevName'
> > $ svn log --revision `myrevnum MyRevName`
>
>
>This is the feature that doesn't yet exist. Ideally, we'd want all svn
>subcommands to understand "-r NAME", and look for a specific property on
>each revision.
>
>
>
>---------------------------------------------------------------------
>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
Re: Thanks and a global versioning question; WAS:: Help: XML Pars
er e rror, Date Conversion failed
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-03-23 at 14:40, Brad Appleton wrote:
> - can I create a NAME property for a global revision number?
> - does it make practical sense to implement a mechanism inside or
> outside of SVN that simply maps revnames to revnums and vis-a-vis?
Hi Brad!
Yes, actually, you can attach any arbitrary properties you want to
revision trees.
> [ e.g., $(revname $(revnum $REVNAME)) eq $REVNAME ]
>
> $ svn commit --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3
> $ myrevmap -revnum 3 -revname MyRevName
Or, with today's svn, you'd just run
$ svn propset -revprop -r3 revname MyRevName
> Associated revision 3 of <??> with 'MyRevName'
> $ svn log --revision `myrevnum MyRevName`
This is the feature that doesn't yet exist. Ideally, we'd want all svn
subcommands to understand "-r NAME", and look for a specific property on
each revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars
er e rror, Date Conversion failed
Posted by Nuutti Kotivuori <na...@iki.fi>.
Brad Appleton wrote:
> Okay. So it sounds like the request sint so much concerned about
> tagging as it is about having the ability to associate the
> revision number with a more mnemonic alphanumeric identifier
> (but nonetheless unique), and to be able to use either the
> global revNUM or the global revNAME almost interchangeably in SVN.
Yeah, it's not entirely an uncommon request.
> What are some of the different ways I can do this in SVN, and how
> practical is each and how feasible is it to automate?
Let's see.
> - one approach "psychotic tagging", is apparently not recommended :-)
Well, not entirely unrecommended either. If you want it, you can have
it. For example, making a toplevel directory "revnames" and copying
each commit there under a descriptive name is a definite
possibility. Obviously no-one would wish to check out that directory,
but no-one should have a need to, either.
> - what if I associate the identifier in the log?
Possible, and requires nothing new from Subversion.
> - can I create a NAME property for a global revision number?
Also possible. Revisions have normally three properties: author, date
and log message. You can add more if you want. The only catch here is
that I don't think it is possible to add a revision property that
appears at commit time (with the subversion client), but you can add
it after the commit.
> - does it make practical sense to implement a mechanism inside or
> outside of SVN that simply maps revnames to revnums and vis-a-vis?
> [ e.g., $(revname $(revnum $REVNAME)) eq $REVNAME ]
>
> $ svn commit --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3
> $ myrevmap -revnum 3 -revname MyRevName
> Associated revision 3 of <??> with 'MyRevName'
> $ svn log --revision `myrevnum MyRevName`
Works splendidly - if it would be practical in use, I couldn't say.
> or use a NAME= keyword for the --revision option and commit command,
> as in:
>
> ## NOTE: sample possible syntax - NOT an actual working example!!
> $ svn commit --name MyRevName --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3 (NAME=MyRevName)
> $ svn log --revision NAME=MyRevName
This obviously would require changes to the Subversion client - but it
is by no means a big change. "--name" could be just another revision
property.
> If something like that was worthwhile, then one could perhaps
> implement a pre-commit trigger (or some other mechanism)
> to somehow force a name to entered (or deduced).
Pre-commit-hooks can inspect a commit that is about to happen, and
reject it based on the contents or the log message or whatever. It
could certainly enforce naming revisions.
***
We can even for a moment discuss the actual features of such a thing
being added to Subversion.
First of all, since what we want is being able to map revision names
to revision numbers, we would most definitely need a new table in the
subversion database for this. This can be done without breaking our
version compatibility guarantees at 1.1 if wished.
Like you suggest, "svn commit" could take a "--name something" as a
parameter naming the revision being committed. The name could be a
revision property on the commit, and it could be afterwards modified
with the normal revision property modification methods. The only
special thing about it would be that it automatically updates the
revision name table as well, and enforces uniqueness.
All the Subversion commands taking revision arguments could take in
the new revision names directly. Right now, we accept HEAD, BASE,
COMMITTED and PREV as special (and {DATE}), so we could just rule
those as special (or rule all-caps names special) and just restrict
problematic characters in the revision names. Then a simple usage of
"svn log -r foo:bar" could use the revision names.
So, what could be done with these? Well, for example per project
revisions. Instead of having a global revision of "15242" for a
commit, you could add "project-242" as a revision name. I'm sure
everybody can come up with plenty of uses.
The problem with these would be that they would be indeed global. You
can't tag a copy of a directory with "last-merge" without problems,
instead you'd have to have something like "proj-a-dir-xyz-last-merge".
There would be some churn in the server side for implementation of
this, and possibly in the protocols and interfaces - but it would not
be a huge change to make, and it could be made for 1.1 by the
compatibility guidelines.
***
But, is it worthwhile to make this change? Everybody has their own
opinion ofcourse, but right now I don't think so. Tagging covers
already 95% of the use cases and a lot of the rest can be handled
outside Subversion. Creating a new method for doing mostly the same
thing will add confusion, and make people tag less - which makes them
stick to the old CVS-style habits even where proper tagging would be
the better choice. But, it can be argued both ways - and the
suggestion probably has still a lot to improve on to be even more
useful and worthwhile again.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars
er e rror, Date Conversion failed
Posted by Nuutti Kotivuori <na...@iki.fi>.
Brad Appleton wrote:
> However, I would still want a way to associate a name with a
> revision-number that was simply an alias for the revision-number
> and didn't create a new copy in the pathspace because I don't
> want that level of visibility for every commit - just the
> ability to use a pseudonym for global revision number. The
> example I gave of a 'NAME=' revision keyword would do this,
> and (unlike a property I assume?) be able to be used in
> revision ranges given to svn log and svn diff.
Remember that the Subversion pathspace is hierarchical - and nobody in
their sane minds will checkout all of it.
So, for example, you could create "revnames" directory somewhere, and
stash them all there. The revision names there could be used without
anyone ever taking a directory listing of that - and it would even
enforce uniqueness, since overwriting a directory is not allowed (by
the Subversion client). Or, if you wish to have decent listings of
tags as well, you can organize them hierarchically by project and by
purpose. Or whatever.
If you think that creating a new copy in the pathspace gives too much
visibility, it is time to organize the pathspace so that it does
not. Subversion is giving you all the tools to decide your own
conventions, but it is up to you to find the conventions that work for
you.
Hell, you could write a book on Subversion repository pathspace
patterns ;-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars er e rror, Date Conversion failed
Posted by Brad Appleton <br...@bradapp.net>.
On Tue, Mar 23, 2004 at 04:04:19PM -0500, Francois Beausoleil wrote:
> Hello Brad !
>
> On Tue, 23 Mar 2004 14:40:19 -0600, "Brad Appleton" <br...@bradapp.net>
> said:
> > On Tue, Mar 23, 2004 at 02:10:24PM -0600, C. Michael Pilato wrote:
> > $ svn commit --message "Corrected # of cheese slices."
> > Sending sandwich.txt
> > Transmitting file data .
> > Committed revision 3
> > $ myrevmap -revnum 3 -revname MyRevName
> > Associated revision 3 of <??> with 'MyRevName'
> > $ svn log --revision `myrevnum MyRevName`
Note that there was some more text above that discussing other
possible alternatives (one of which was tagging).
> Why can't you just do:
> $ svn commit --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3
> $ svn copy --message "Tagging release 4.0.1-b2" --revision 3
> svn://server/svn/path/to/project
> svn://server/svn/path/to/tags/RELEASE_4_0_1-b2
> Committed revision 4
Yes. That was the first alternative discussed (and the person
wanted a way for that to happen automatically). Speaking for
me personally, I wouldn't use a tag unless what I really wanted
was a tag that included a corresponding working-copy that would
show up in the svn pathspace. I would not do that for every
commit, only for "special ones".
However, I would still want a way to associate a name with a
revision-number that was simply an alias for the revision-number
and didn't create a new copy in the pathspace because I don't
want that level of visibility for every commit - just the
ability to use a pseudonym for global revision number. The
example I gave of a 'NAME=' revision keyword would do this,
and (unlike a property I assume?) be able to be used in
revision ranges given to svn log and svn diff.
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars er e rror, Date Conversion failed
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
Hello Brad !
On Tue, 23 Mar 2004 14:40:19 -0600, "Brad Appleton" <br...@bradapp.net>
said:
> On Tue, Mar 23, 2004 at 02:10:24PM -0600, C. Michael Pilato wrote:
> $ svn commit --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3
> $ myrevmap -revnum 3 -revname MyRevName
> Associated revision 3 of <??> with 'MyRevName'
> $ svn log --revision `myrevnum MyRevName`
Why can't you just do:
$ svn commit --message "Corrected # of cheese slices."
Sending sandwich.txt
Transmitting file data .
Committed revision 3
$ svn copy --message "Tagging release 4.0.1-b2" --revision 3
svn://server/svn/path/to/project
svn://server/svn/path/to/tags/RELEASE_4_0_1-b2
Committed revision 4
This way, you can run log just like you wanted:
$ svn log svn://server/svn/path/to/tags/tags/RELEASE_4_0_1-b2
rev 4 | ...
Tagging release 4.0.1-b2
rev 3 | ...
Corrected # of cheese slices.
So, why can't you ?
Bye !
François
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars er e rror, Date Conversion failed
Posted by Brad Appleton <br...@bradapp.net>.
On Tue, Mar 23, 2004 at 02:10:24PM -0600, C. Michael Pilato wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
> > Your proposal was to automatically make a tag after *every* commit.
> > That's psychotic tagging. :-) There are thousands and thousands of
> > commits. Surely not every single commit to the repository is worth
> > tagging!
>
> Of course not every commit is worth tagging -- because it already *is*
> (effectively) tagged. We just call those tags "revision numbers". :-)
Okay. So it sounds like the request sint so much concerned about
tagging as it is about having the ability to associate the
revision number with a more mnemonic alphanumeric identifier
(but nonetheless unique), and to be able to use either the
global revNUM or the global revNAME almost interchangeably in SVN.
What are some of the different ways I can do this in SVN, and how
practical is each and how feasible is it to automate?
- one approach "psychotic tagging", is apparently not recommended :-)
- what if I associate the identifier in the log?
- can I create a NAME property for a global revision number?
- does it make practical sense to implement a mechanism inside or
outside of SVN that simply maps revnames to revnums and vis-a-vis?
[ e.g., $(revname $(revnum $REVNAME)) eq $REVNAME ]
$ svn commit --message "Corrected # of cheese slices."
Sending sandwich.txt
Transmitting file data .
Committed revision 3
$ myrevmap -revnum 3 -revname MyRevName
Associated revision 3 of <??> with 'MyRevName'
$ svn log --revision `myrevnum MyRevName`
or use a NAME= keyword for the --revision option and commit command,
as in:
## NOTE: sample possible syntax - NOT an actual working example!!
$ svn commit --name MyRevName --message "Corrected # of cheese slices."
Sending sandwich.txt
Transmitting file data .
Committed revision 3 (NAME=MyRevName)
$ svn log --revision NAME=MyRevName
If something like that was worthwhile, then one could perhaps
implement a pre-commit trigger (or some other mechanism)
to somehow force a name to entered (or deduced).
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Thanks and a global versioning question; WAS:: Help: XML Pars er e rror, Date Conversion failed
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Your proposal was to automatically make a tag after *every* commit.
> That's psychotic tagging. :-) There are thousands and thousands of
> commits. Surely not every single commit to the repository is worth
> tagging!
Of course not every commit is worth tagging -- because it already *is*
(effectively) tagged. We just call those tags "revision numbers". :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
{Spam?} Re: {Spam?} RE: Thanks and a global versioning question; WAS:: Help: XML Parser e rror, Date Conversion failed
Posted by Jeremy Bettis <je...@deadbeef.com>.
> On Tue, 2004-03-23 at 13:54, Crucius, Wesley wrote:
> Like any project, you make tags only once in a while... when you make a
> snapshot for a release to specific customer, for example. This pattern
> is universal for any version control system, so of course you would
> continue doing this in Subversion as well.
I have a related, but normal tagging, question. I am tagging every customer
release, and I'd like to make a document that listed the svn log messages
for all revisions from one release to another.
How do I do that? svn diff will take two url's but svn log will not.
I really want to do something like:
svn log -r HEAD:http://server/svn/tags/release6
http://server/svn/tags/release7
But I can't. I suspect that I need to do something like:
oldtag=`svn log http://server/svn/tags/release6 --stop-on-copy -q | awk
'/^r/ {print $1}' | sed 's/r//' | tail -1`
newtag=`svn log http://server/svn/tags/release7 --stop-on-copy -q | awk
'/^r/ {print $1}' | sed 's/r//' | tail -1`
svn log -r $newtag:$oldtag http://server/svn/trunk -v >changes.txt
Is there a way to simplify this? And my tags aren't really that simple,
since they contain multiple directories that came from different places in
trunk. svn diff does exactly what I want, except that I just want the log
entries not the code changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Thanks and a global versioning question; WAS:: Help: XML Pars
er e rror, Date Conversion failed
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-03-23 at 13:54, Crucius, Wesley wrote:
> Am I all wet, or is this making sense?
No, your use cases make sense, but I think you're confusing "normal"
tagging patterns with "psychotic" tagging patterns.
Like any project, you make tags only once in a while... when you make a
snapshot for a release to specific customer, for example. This pattern
is universal for any version control system, so of course you would
continue doing this in Subversion as well.
Your proposal was to automatically make a tag after *every* commit.
That's psychotic tagging. :-) There are thousands and thousands of
commits. Surely not every single commit to the repository is worth
tagging!
Have you read chapters 2, 3, and 4 in the book? I can't quite tell.
Global version numbers really have nothing to do with branching and
tagging patterns, but in your mind, you're somehow relating them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org