You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Povilaitis <st...@gmail.com> on 2008/09/16 13:32:57 UTC
help me show others that there are valid reasons for not supporting a $log$ keyword!
Most exalted ones,
Our program management is clamoring for including a revision history like
the old cvs $log$ keyword at the beginning of every file. I know there are
good reasons for not supporting a $log$ keyword or even the idea of
including a running log in the file, but if I'm not able to make a case for
abandoning the idea, I'm going to be forced into writing some sort of kludgy
script to do just that. I've searched previous posts explaining why this is
a bad idea and this is my understanding of some of the key points:
1. It's dumb to include version history in the file since this is meta-data
that is implicitly part of the versioning system, and there are better ways
of using subversion to get this data in much more understandable/useful
formats.
2. Having a large block of text at the front of the file is unwieldy and
confuses external diff tools.
3. It messes up binary files
4. Possible merge conflicts
What else folks?
Also, for every tagged release we do for the customer they're going to want
an export of the source with the revision log for each file appended to the
beginning of the file. Have any of you had to do something along those lines
and would you mind sharing how you accomplished it?
thanks!
Steve
Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Alec Kloss <al...@oracle.com>.
On 2008-09-16 09:32, Steve Povilaitis wrote:
[chop]
>
> What else folks?
Well, any argument against any of the svn:keywords works for log
too. $log$ is just worse than the other substitutions.
> Also, for every tagged release we do for the customer they're going to want
> an export of the source with the revision log for each file appended to the
> beginning of the file. Have any of you had to do something along those lines
> and would you mind sharing how you accomplished it?
I think it's common to try to use substitution keywords in the
source control system to handle release engineering problems
like this. The releng I take care of stamps the current revision
number of the repository and other interesting facts into the
source files prior to compiling them and then stamps the object
files with a SHA-1 digest of their content for tamper/error
detection. There's no reason I couldn't stick an entire svn log
into the source files prior to building them. Assuming your
sources are archived permanently for a release build, I don't
really see anything wrong with stamping the log into them. If
disaster strikes and your repository is irreparibly destroyed,
your archived release sources have some extra information in them.
Of course, it'd be smarter to just archive your whole repository at
release time and put it in the safe place where your archived
sources would go instead. If you're truly worried about the end
times, keep a copy of your compilers, subversion itself, and your
releng OS in the same super-safe place. That's my $0.02.
--
Alec.Kloss@oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
Re: help me show others that there are valid reasons for not supporting
a $log$ keyword!
Posted by John Allen <jo...@dublinux.net>.
Steve Povilaitis wrote:
>
>
> On Tue, Sep 16, 2008 at 10:48 AM, Parrish, Ken <KParrish@gomez.com
> <ma...@gomez.com>> wrote:
>
> >>
> > Another argument for you (and kind of addressed in the FAQ): in
> > Subversion, logs are NOT file-centric. They are based upon the
> > revision. It is not possible to pull the log messages for a single
> > file. You can pull the log messages for all revisions in which the
> > file in question was edited, but you can't differentiate which
> > portions of the log message apply to which file (unless you have a
> > strict structure to those log messages).
>
> I think this is an especially strong argument. Neither, is there any
> practical sense in checking in each file independently so that
> each can
> have a separate log.
>
> You might also argue that there is fundamental difference between the
> revision management that takes place in Subversion and what might
> really
> be their objective which is sensible and useful Configuration
> Management
> information.
>
> Although they might be asking for keyword / log substitution, it would
> interesting to understand why it is so important to them and what
> problem they are really trying to solve.
>
> Using a tool like Nant, it is a straightforward process to
> automate the
> generation of a revision log, save it to a file, e-mail it, put it
> in a
> database, etc.
>
> I would also advocate for the generation and storage of change lists
> and/or change logs as part of a configuration management function. I
> have found that these lists, more than any other information,
> allay the
> 'nervousness' created by managers about new versions and releases of
> software. If they are presented with a change list that clearly and
> unambiguously shows what has changed since the 'previous version',
> they
> seem to relax about other 'illogical' requests.
>
> My $.02 as well.
>
> Ken Parrish
>
> Thanks Ken,
>
> I plan to advocate for your suggestions. Can you provide some more
> insight into how you would structure a changelog? I'm thinking
> something along the lines of a list of all the files that were changed
> since the last release. Would you also include a diff of those file
> from the previous release?
For each revision from previous release to current release (in reverse
order)
list of files, and log message.
eg.
r15678
Added additional checking around user specified files
src/main/io/
src/main/tests
r15677
Ensure output files are created with the correct permissions
src/main/io/
src/main/tests
.
.
.
.
.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Steve Povilaitis <st...@gmail.com>.
On Tue, Sep 16, 2008 at 10:48 AM, Parrish, Ken <KP...@gomez.com> wrote:
> >>
> > Another argument for you (and kind of addressed in the FAQ): in
> > Subversion, logs are NOT file-centric. They are based upon the
> > revision. It is not possible to pull the log messages for a single
> > file. You can pull the log messages for all revisions in which the
> > file in question was edited, but you can't differentiate which
> > portions of the log message apply to which file (unless you have a
> > strict structure to those log messages).
>
> I think this is an especially strong argument. Neither, is there any
> practical sense in checking in each file independently so that each can
> have a separate log.
>
> You might also argue that there is fundamental difference between the
> revision management that takes place in Subversion and what might really
> be their objective which is sensible and useful Configuration Management
> information.
>
> Although they might be asking for keyword / log substitution, it would
> interesting to understand why it is so important to them and what
> problem they are really trying to solve.
>
> Using a tool like Nant, it is a straightforward process to automate the
> generation of a revision log, save it to a file, e-mail it, put it in a
> database, etc.
>
> I would also advocate for the generation and storage of change lists
> and/or change logs as part of a configuration management function. I
> have found that these lists, more than any other information, allay the
> 'nervousness' created by managers about new versions and releases of
> software. If they are presented with a change list that clearly and
> unambiguously shows what has changed since the 'previous version', they
> seem to relax about other 'illogical' requests.
>
> My $.02 as well.
>
> Ken Parrish
>
Thanks Ken,
I plan to advocate for your suggestions. Can you provide some more insight
into how you would structure a changelog? I'm thinking something along the
lines of a list of all the files that were changed since the last release.
Would you also include a diff of those file from the previous release?
RE: Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by "Parrish, Ken" <KP...@gomez.com>.
>>
> Another argument for you (and kind of addressed in the FAQ): in
> Subversion, logs are NOT file-centric. They are based upon the
> revision. It is not possible to pull the log messages for a single
> file. You can pull the log messages for all revisions in which the
> file in question was edited, but you can't differentiate which
> portions of the log message apply to which file (unless you have a
> strict structure to those log messages).
I think this is an especially strong argument. Neither, is there any
practical sense in checking in each file independently so that each can
have a separate log.
You might also argue that there is fundamental difference between the
revision management that takes place in Subversion and what might really
be their objective which is sensible and useful Configuration Management
information.
Although they might be asking for keyword / log substitution, it would
interesting to understand why it is so important to them and what
problem they are really trying to solve.
Using a tool like Nant, it is a straightforward process to automate the
generation of a revision log, save it to a file, e-mail it, put it in a
database, etc.
I would also advocate for the generation and storage of change lists
and/or change logs as part of a configuration management function. I
have found that these lists, more than any other information, allay the
'nervousness' created by managers about new versions and releases of
software. If they are presented with a change list that clearly and
unambiguously shows what has changed since the 'previous version', they
seem to relax about other 'illogical' requests.
My $.02 as well.
Ken Parrish
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Steve Povilaitis <st...@gmail.com>.
>
>
> Another argument for you (and kind of addressed in the FAQ): in
> Subversion, logs are NOT file-centric. They are based upon the
> revision. It is not possible to pull the log messages for a single
> file. You can pull the log messages for all revisions in which the
> file in question was edited, but you can't differentiate which
> portions of the log message apply to which file (unless you have a
> strict structure to those log messages).
That's a good point - thanks for mentioning it.
>
>
> > Also, for every tagged release we do for the customer they're going to
> want
> > an export of the source with the revision log for each file appended to
> the
> > beginning of the file. Have any of you had to do something along those
> lines
> > and would you mind sharing how you accomplished it?
>
> That makes no sense at all. You should be publishing a single
> changelist saying "here's what changed since your last release."
>
I agree with you 100%, unfortunately to paraphrase the warden in the movie
Cool Hand Luke "That's the way he wants it, well, he gets it. I don't like
it anymore than you."
I am scheduling a conference with the folks from on high to get a better
understanding of just what they want to accomplish and if there are some
better ways their needs can be met, but It's going to be an uphill battle.
Re: help me show others that there are valid reasons for not
supporting a $log$ keyword!
Posted by "Robert P. J. Day" <rp...@crashcourse.ca>.
Quoting Andy Levy <an...@gmail.com>:
> That makes no sense at all. You should be publishing a single
> changelist saying "here's what changed since your last release."
pedantically speaking, i might avoid the use of the word
"changelist" here. "ChangeLog" would probably be safer. :-)
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Andy Levy <an...@gmail.com>.
On Tue, Sep 16, 2008 at 09:32, Steve Povilaitis <st...@gmail.com> wrote:
> Most exalted ones,
>
> Our program management is clamoring for including a revision history like
> the old cvs $log$ keyword at the beginning of every file. I know there are
> good reasons for not supporting a $log$ keyword or even the idea of
> including a running log in the file, but if I'm not able to make a case for
> abandoning the idea, I'm going to be forced into writing some sort of kludgy
> script to do just that. I've searched previous posts explaining why this is
> a bad idea and this is my understanding of some of the key points:
>
> 1. It's dumb to include version history in the file since this is meta-data
> that is implicitly part of the versioning system, and there are better ways
> of using subversion to get this data in much more understandable/useful
> formats.
> 2. Having a large block of text at the front of the file is unwieldy and
> confuses external diff tools.
> 3. It messes up binary files
> 4. Possible merge conflicts
>
> What else folks?
You've nailed the best ones so far. If you haven't already, also have
a look at http://subversion.tigris.org/faq.html#log-in-source
Another argument for you (and kind of addressed in the FAQ): in
Subversion, logs are NOT file-centric. They are based upon the
revision. It is not possible to pull the log messages for a single
file. You can pull the log messages for all revisions in which the
file in question was edited, but you can't differentiate which
portions of the log message apply to which file (unless you have a
strict structure to those log messages).
> Also, for every tagged release we do for the customer they're going to want
> an export of the source with the revision log for each file appended to the
> beginning of the file. Have any of you had to do something along those lines
> and would you mind sharing how you accomplished it?
That makes no sense at all. You should be publishing a single
changelist saying "here's what changed since your last release."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Steve Povilaitis <st...@gmail.com>.
>
>
> > On Tue, Sep 16, 2008 at 15:29, Ryan Schmidt
> > <su...@ryandesign.com> wrote:
> > > On Sep 16, 2008, at 11:04 AM, Robert P. J. Day wrote:
> > >
> > I suspect, from what the OP has written, that his management will opt
> > for the former if you give them any possible opening to squeeze
> > through.
> >
>
> Too true.
>
> Simply state that implementing $log$ "can't be done" (it's not
> practical.) "It cannot be done, so we either have to do without, or we
> can use the following alternatives..."
>
> Give them an alternative. One reason for putting $log$ into files is
> because in a lot of systems, it's a pain to get the information from the
> tool. However, Subversion makes it really easy to get meta-information.
> For example: you can use the $URL$ keyword (which puts
> "svn://server/repos/a/b/c/foo.java" into your file) and then simply run
> "svn log svn://server/repos/a/b/c/foo.java" from the command line, via a
> web browser (tortoise has a browser plugin, just type in the
> svn://repos/some/foo.java and away you go,) or in a spiffy GUI like
> TortoiseSVN to get the log history. This also has the advantage of
> being up to date (log messages can be changed,) you can do diffs, run
> annotate, etc.. _Everyone_ understands how web URLs work. $URL$ is a
> web URL. Typing "svn log some_url" shouldn't be difficult.
>
> People put $log$ in the file because of convenience. Show them that SVN
> is convenient, but more so. Demo'ing the 'svn log/diff/annotate URL'
> feature before a live audience (especially if you use a GUI) should go a
> long way to winning over people.
>
>
> Now if your customers cannot reach the subversion server, then modify
> your export script/build package to run 'svn log' for each file and save
> it as "foo.java.log". They get the log history. It's easy to
> understand that foo.java.log is the log history for foo.java. If they
> still complain about such a "simple and effective solution," then ask
> them to explain what the problem is (being too lazy to open a 2nd file
> isn't going to fly.) Worst case would be that they have some automated
> process which is parsing $log$, although data-mining $log$ would seem to
> be of dubious value.
>
> You could have the build/export prepend the 'svn log' to each file,
> however, eventually Someone(tm) _will_ cause havoc by checking in a file
> with the log information, so don't do it. (Breaks diffs, breaks merges,
> the log info is out of date immediately, the next export will add a 2nd
> log history, etc.)
>
>
> Thanks for the ideas. I really appreciate it. I don't think the decision
makers in this case have ever seen a distributed versioning system with a
web front end or an integrated tool like Trac, so they aren't capable of
thinking outside of their text based frame of reference.
Unfortunately after a teleconference yesterday the program management made
it clear that they aren't interested in hearing the benefits of any new
approaches. The corporate 'approved' versioning system is a monolithic app
which is based on the old checkout-lock-checkin paradigm, and does the $log$
thing. So we're going to have to bend SVN to support that notion or just
drop it altogether.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
RE: Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Tuesday, September 16, 2008 3:33 PM
> To: Ryan Schmidt
> Cc: Robert P. J. Day; users@subversion.tigris.org
> Subject: Re: help me show others that there are valid reasons for not
> supporting a $log$ keyword!
>
> On Tue, Sep 16, 2008 at 15:29, Ryan Schmidt
> <su...@ryandesign.com> wrote:
> > On Sep 16, 2008, at 11:04 AM, Robert P. J. Day wrote:
> >
> I suspect, from what the OP has written, that his management will opt
> for the former if you give them any possible opening to squeeze
> through.
>
Too true.
Simply state that implementing $log$ "can't be done" (it's not
practical.) "It cannot be done, so we either have to do without, or we
can use the following alternatives..."
Give them an alternative. One reason for putting $log$ into files is
because in a lot of systems, it's a pain to get the information from the
tool. However, Subversion makes it really easy to get meta-information.
For example: you can use the $URL$ keyword (which puts
"svn://server/repos/a/b/c/foo.java" into your file) and then simply run
"svn log svn://server/repos/a/b/c/foo.java" from the command line, via a
web browser (tortoise has a browser plugin, just type in the
svn://repos/some/foo.java and away you go,) or in a spiffy GUI like
TortoiseSVN to get the log history. This also has the advantage of
being up to date (log messages can be changed,) you can do diffs, run
annotate, etc.. _Everyone_ understands how web URLs work. $URL$ is a
web URL. Typing "svn log some_url" shouldn't be difficult.
People put $log$ in the file because of convenience. Show them that SVN
is convenient, but more so. Demo'ing the 'svn log/diff/annotate URL'
feature before a live audience (especially if you use a GUI) should go a
long way to winning over people.
Now if your customers cannot reach the subversion server, then modify
your export script/build package to run 'svn log' for each file and save
it as "foo.java.log". They get the log history. It's easy to
understand that foo.java.log is the log history for foo.java. If they
still complain about such a "simple and effective solution," then ask
them to explain what the problem is (being too lazy to open a 2nd file
isn't going to fly.) Worst case would be that they have some automated
process which is parsing $log$, although data-mining $log$ would seem to
be of dubious value.
You could have the build/export prepend the 'svn log' to each file,
however, eventually Someone(tm) _will_ cause havoc by checking in a file
with the log information, so don't do it. (Breaks diffs, breaks merges,
the log info is out of date immediately, the next export will add a 2nd
log history, etc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Andy Levy <an...@gmail.com>.
On Tue, Sep 16, 2008 at 15:29, Ryan Schmidt
<su...@ryandesign.com> wrote:
> On Sep 16, 2008, at 11:04 AM, Robert P. J. Day wrote:
>
>> Quoting "Reedick, Andrew":
>>
>>> What is the goal/purpose/benefit of the log? If SVN can provide or meet
>>> that goal/purpose/benefit, then it shouldn't matter how it's implemented.
>>> Don't force the Old Inefficient Ways on New Tools.
>>
>> that will *not* be a compelling argument. the normal response to
>> that is, "but it won't *hurt*, will it?" when people are absolutely
>> entrenched in their ways, it is not enough to show that some old
>> habit no longer has any value. you have to go further and show that
>> it actually *harms* the process, however you want to do that.
>>
>> trust me, i've been down this road before. you need to demonstrate
>> actual harm. if you can't, you're going to lose this one.
>
> My argument would be:
>
> Subversion does not have the function in question ($Log$ in source). The
> developers of Subversion will not implement it or accept a patch which
> implements it. So you can either waste a lot of time implementing it
> yourself and maintaining it forever, or you can understand why it's not a
> good idea and do something else that is supported. :-)
I suspect, from what the OP has written, that his management will opt
for the former if you give them any possible opening to squeeze
through.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 16, 2008, at 11:04 AM, Robert P. J. Day wrote:
> Quoting "Reedick, Andrew":
>
>> What is the goal/purpose/benefit of the log? If SVN can provide
>> or meet that goal/purpose/benefit, then it shouldn't matter how
>> it's implemented. Don't force the Old Inefficient Ways on New
>> Tools.
>
> that will *not* be a compelling argument. the normal response to
> that is, "but it won't *hurt*, will it?" when people are absolutely
> entrenched in their ways, it is not enough to show that some old
> habit no longer has any value. you have to go further and show that
> it actually *harms* the process, however you want to do that.
>
> trust me, i've been down this road before. you need to demonstrate
> actual harm. if you can't, you're going to lose this one.
My argument would be:
Subversion does not have the function in question ($Log$ in source).
The developers of Subversion will not implement it or accept a patch
which implements it. So you can either waste a lot of time
implementing it yourself and maintaining it forever, or you can
understand why it's not a good idea and do something else that is
supported. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: help me show others that there are valid reasons for not
supporting a $log$ keyword!
Posted by "Robert P. J. Day" <rp...@crashcourse.ca>.
Quoting "Reedick, Andrew" <jr...@ATT.COM>:
>> From: Steve Povilaitis [mailto:stevepov@gmail.com]
>> Our program management is clamoring for including a
>> revision history like the old cvs $log$ keyword at the
>> beginning of every file. I know there are good reasons for
>> not supporting a $log$ keyword or even the idea of
>> including a running log in the file, but if I'm not able
>> to make a case for abandoning the idea, I'm going to be
>> forced into writing some sort of kludgy script to do just
>> that. I've searched previous posts explaining why this is
>> a bad idea and this is my understanding of some of the key
>> points:
>
> Turn the question around. What are the benefits of putting the log
> history in each file?
>
> What is the goal/purpose/benefit of the log? If SVN can provide or
> meet that goal/purpose/benefit, then it shouldn't matter how it's
> implemented. Don't force the Old Inefficient Ways on New Tools.
that will *not* be a compelling argument. the normal response to
that is, "but it won't *hurt*, will it?" when people are absolutely
entrenched in their ways, it is not enough to show that some old
habit no longer has any value. you have to go further and show that
it actually *harms* the process, however you want to do that.
trust me, i've been down this road before. you need to demonstrate
actual harm. if you can't, you're going to lose this one.
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: help me show others that there are valid reasons for not supporting a $log$ keyword!
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> From: Steve Povilaitis [mailto:stevepov@gmail.com]
> Sent: Tuesday, September 16, 2008 9:33 AM
> To: users@subversion.tigris.org
> Subject: help me show others that there are valid reasons
> for not supporting a $log$ keyword!
> Our program management is clamoring for including a
> revision history like the old cvs $log$ keyword at the
> beginning of every file. I know there are good reasons for
> not supporting a $log$ keyword or even the idea of
> including a running log in the file, but if I'm not able
> to make a case for abandoning the idea, I'm going to be
> forced into writing some sort of kludgy script to do just
> that. I've searched previous posts explaining why this is
> a bad idea and this is my understanding of some of the key
> points:
Turn the question around. What are the benefits of putting the log history in each file?
What is the goal/purpose/benefit of the log? If SVN can provide or meet that goal/purpose/benefit, then it shouldn't matter how it's implemented. Don't force the Old Inefficient Ways on New Tools. There's a reason why automobiles are not equipped with buggy whips, and why horse buggies don't have air conditioning, headlights, turn signals, airbags, and anti-lock brakes that can safely stop two tons of metal going 60+ miles per hour.
Paradigm shift. As others have pointed out, SVN logging on a per file basis doesn't make sense. CVS *has* to put the log history in each file because CVS is primitive and only manages change on per file basis (each file is a database object with its own history and version tree.) By comparison SVN manages change sets across multiple files and logs as a whole, instead of as a sum of the parts.
Make the transition easy. When you deliver code, simply run 'svn log' at the top dir and send that change log as a file in the package. You may also want to provide a tool/script to easily pull the revision history for individual files.
Plan B. Why are you delivering source code? SVN has a web interface. SVN repositories can also be accessed over the internet, which not only gives you logging, it also provides the ability to do diffs! $log$ *assumes* that you use accurate and meaningful comments. Diff'ing lets you see what really changed. IIRC, SVN 1.5 also supports replicated repositories.
> 2. Having a large block of text at the front of the file
> is unwieldy and confuses external diff tools.
> 3. It messes up binary files
> 4. Possible merge conflicts
In other words, $log$ lowers code quality...
Finally, $log$ is *not* a replacement for a proper changelist or a ticket list. $log$ isn't guaranteed to be accurate, nor is it organized, and most importantly, test cases aren't run against $log$. Test cases are run against tickets, change sets, features, or requirements, which is the information that should be used to create a proper, accurate and useful changelist.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org