You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by nick vajberg <ni...@yahoo.dk> on 2003/11/26 12:54:56 UTC
Feature requests for post 1.0
1) New svn:keyword : History. This would replace
$History$ with a verbose, nicely formatted history of
the file. We have to distribute source files gzip'ed
and the recipient require history comments in each
file header. Updating the history manually is very
time consuming and errorphrone. Any thoughts?
2) I use svn propset to add the standard props (URL,
Author, Rev and Id). Very useful way to annotate
source code automatically!
However, when we add new files to certain directories,
we would very much like those files to get these
properties automatically upon commit. We often forget
to run a new svn propset after adding new files.
I guess what I'm asking for is this: "svn propset
svn:keywords ... c:\myproject\src --auto" or something
similar.
All existing and future files in the src directory
would get the props upon commit. I guess a pre-commit
script could do this, but a built-in solution would be
nice.
Any thoughts on this?
Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by Branko Čibej <br...@xbc.nu>.
David Waite wrote:
> Perhaps a compromise would be to perform this history tag expansion
> only on export?
Compromise [n.] -- A state of affairs where all parties in a negotiation
are unsatisfied, but with the consolation that at least they screwed the
other guy, too.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Nov 26, 2003 at 11:11:57AM -0600, kfogel@collab.net wrote:
> David Waite <ma...@akuma.org> writes:
> > Perhaps a compromise would be to perform this history tag expansion
> > only on export?
>
This could be accomplished via a wrapper and/or swig script, perhaps in
contrib or tools.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by kf...@collab.net.
David Waite <ma...@akuma.org> writes:
> Perhaps a compromise would be to perform this history tag expansion
> only on export?
We're getting into real edge-case territory here, and the ratio
benefit
------------------
maintenance burden
diminishes. I'm not going to say -1, since there's no concrete
proposal yet, but -0.9 on the general idea :-).
Subversion generally separates historical metadata and file contents.
To start blending them is to create a different kind of system, and we
haven't even begun to think about the design implications of that.
-Karl
> On Nov 26, 2003, at 9:59 AM, Greg Hudson wrote:
>
> > On Wed, 2003-11-26 at 07:54, nick vajberg wrote:
> >> 1) New svn:keyword : History. This would replace
> >> $History$ with a verbose, nicely formatted history of
> >> the file. We have to distribute source files gzip'ed
> >> and the recipient require history comments in each
> >> file header. Updating the history manually is very
> >> time consuming and errorphrone. Any thoughts?
> >
> > I'll assume you want this to behave like an actual keyword, not like
> > the
> > $Log$ pseudo-keyword in RCS/CVS (where history information is added
> > incrementally after the $Log$ keyword, certain operations can mess up
> > the history, and there's no way to prevent merge conflicts resulting
> > from the history).
> >
> > Our translation code assumes that keywords are short and can't span
> > multiple lines. That could change, but if the keyword text which needs
> > to be substituted can be very long ("$History: <100Kbytes here>"), then
> > substitution can't be done streamily. If you read "$History:" followed
> > by a million bytes, and the end of the file comes before the closing
> > '$', then you didn't really have a keyword, so you have to put those
> > million bytes back in untouched, so you'd better have been saving them.
> > Not the end of the world, maybe, but it's another reason why it's a
> > pain
> > in the ass.
> >
> > If dollar signs appear in the log, they'd have to be quoted, which kind
> > of interferes with the "nicely formatted" part.
> >
> > Fetching the log information for a file during translation is would
> > require opening an extra repository session for that purpose. Doable,
> > but also a pain in the ass, and it isn't 100% transparent to the user
> > (for instance, if you use svn+ssh and ssh requires a password, opening
> > an extra session means being asked for your password an extra time).
> >
> > So, nobody here is likely to devote time to it, and even if someone
> > wrote a patch, we'd be very leary of committing it.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by David Waite <ma...@akuma.org>.
Perhaps a compromise would be to perform this history tag expansion
only on export?
-David Waite
On Nov 26, 2003, at 9:59 AM, Greg Hudson wrote:
> On Wed, 2003-11-26 at 07:54, nick vajberg wrote:
>> 1) New svn:keyword : History. This would replace
>> $History$ with a verbose, nicely formatted history of
>> the file. We have to distribute source files gzip'ed
>> and the recipient require history comments in each
>> file header. Updating the history manually is very
>> time consuming and errorphrone. Any thoughts?
>
> I'll assume you want this to behave like an actual keyword, not like
> the
> $Log$ pseudo-keyword in RCS/CVS (where history information is added
> incrementally after the $Log$ keyword, certain operations can mess up
> the history, and there's no way to prevent merge conflicts resulting
> from the history).
>
> Our translation code assumes that keywords are short and can't span
> multiple lines. That could change, but if the keyword text which needs
> to be substituted can be very long ("$History: <100Kbytes here>"), then
> substitution can't be done streamily. If you read "$History:" followed
> by a million bytes, and the end of the file comes before the closing
> '$', then you didn't really have a keyword, so you have to put those
> million bytes back in untouched, so you'd better have been saving them.
> Not the end of the world, maybe, but it's another reason why it's a
> pain
> in the ass.
>
> If dollar signs appear in the log, they'd have to be quoted, which kind
> of interferes with the "nicely formatted" part.
>
> Fetching the log information for a file during translation is would
> require opening an extra repository session for that purpose. Doable,
> but also a pain in the ass, and it isn't 100% transparent to the user
> (for instance, if you use svn+ssh and ssh requires a password, opening
> an extra session means being asked for your password an extra time).
>
> So, nobody here is likely to devote time to it, and even if someone
> wrote a patch, we'd be very leary of committing it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-11-26 at 07:54, nick vajberg wrote:
> 1) New svn:keyword : History. This would replace
> $History$ with a verbose, nicely formatted history of
> the file. We have to distribute source files gzip'ed
> and the recipient require history comments in each
> file header. Updating the history manually is very
> time consuming and errorphrone. Any thoughts?
I'll assume you want this to behave like an actual keyword, not like the
$Log$ pseudo-keyword in RCS/CVS (where history information is added
incrementally after the $Log$ keyword, certain operations can mess up
the history, and there's no way to prevent merge conflicts resulting
from the history).
Our translation code assumes that keywords are short and can't span
multiple lines. That could change, but if the keyword text which needs
to be substituted can be very long ("$History: <100Kbytes here>"), then
substitution can't be done streamily. If you read "$History:" followed
by a million bytes, and the end of the file comes before the closing
'$', then you didn't really have a keyword, so you have to put those
million bytes back in untouched, so you'd better have been saving them.
Not the end of the world, maybe, but it's another reason why it's a pain
in the ass.
If dollar signs appear in the log, they'd have to be quoted, which kind
of interferes with the "nicely formatted" part.
Fetching the log information for a file during translation is would
require opening an extra repository session for that purpose. Doable,
but also a pain in the ass, and it isn't 100% transparent to the user
(for instance, if you use svn+ssh and ssh requires a password, opening
an extra session means being asked for your password an extra time).
So, nobody here is likely to devote time to it, and even if someone
wrote a patch, we'd be very leary of committing it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by kf...@collab.net.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> nick vajberg wrote:
> > 1) New svn:keyword : History. This would replace
> > $History$ with a verbose, nicely formatted history of
> > the file. We have to distribute source files gzip'ed
> > and the recipient require history comments in each
> > file header. Updating the history manually is very
> > time consuming and errorphrone. Any thoughts?
>
> It won't happen. There have been extensive discussions on the list
> about it, and the general consensus is that the history keyword is
> more trouble than it's worth. Search the archives for details.
The discussion was around the $Log$ keyword in CVS, I believe -- that
may help you find it faster.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2003-11-26 at 13:21, nick vajberg wrote:
> > There is already a (not especially well documented)
> > feature that lets
> > you add rules in your config file that specifies
> > what properties get
> > added to files when they're added (like all files
> > who's name match *.c
> > get svn:keywords set to Id or something like that).
>
> Interesting. But can I constrain it to a certain
> directory subtree?
No. It's a global runtime behavior that affects 'svn add' and 'svn
import'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by nick vajberg <ni...@yahoo.dk>.
> There is already a (not especially well documented)
> feature that lets
> you add rules in your config file that specifies
> what properties get
> added to files when they're added (like all files
> who's name match *.c
> get svn:keywords set to Id or something like that).
Interesting. But can I constrain it to a certain
directory subtree?
Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature requests for post 1.0
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
nick vajberg wrote:
> 1) New svn:keyword : History. This would replace
> $History$ with a verbose, nicely formatted history of
> the file. We have to distribute source files gzip'ed
> and the recipient require history comments in each
> file header. Updating the history manually is very
> time consuming and errorphrone. Any thoughts?
It won't happen. There have been extensive discussions on the list
about it, and the general consensus is that the history keyword is more
trouble than it's worth. Search the archives for details.
> 2) I use svn propset to add the standard props (URL,
> Author, Rev and Id). Very useful way to annotate
> source code automatically!
>
> However, when we add new files to certain directories,
> we would very much like those files to get these
> properties automatically upon commit. We often forget
> to run a new svn propset after adding new files.
There is already a (not especially well documented) feature that lets
you add rules in your config file that specifies what properties get
added to files when they're added (like all files who's name match *.c
get svn:keywords set to Id or something like that).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org