You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Alexander L. Belikoff" <ab...@vallinor4.com> on 2004/07/21 12:16:18 UTC
PATCH: $Header$ handling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Attached (and included) is a patch implementing the RCS $Header$ keyword. A
lot of people have been asking for this and quite a lot of people use it a
lot.
With patch applied, svn recognizes a new 'Header' keyword and expands it as:
$Header: file:///home/abel/svnwork/repo/pcre/AUTHORS 5 2004-07-21 12:13:45Z
abel $
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Index: subversion/include/svn_subst.h
===================================================================
- --- subversion/include/svn_subst.h (revision 10373)
+++ subversion/include/svn_subst.h (working copy)
@@ -83,6 +83,7 @@
const svn_string_t *author;
const svn_string_t *url;
const svn_string_t *id;
+ const svn_string_t *header;
} svn_subst_keywords_t;
Index: subversion/include/svn_types.h
===================================================================
- --- subversion/include/svn_types.h (revision 10373)
+++ subversion/include/svn_types.h (working copy)
@@ -283,6 +283,9 @@
*/
#define SVN_KEYWORD_ID "Id"
+/** A dearly missing Header */
+#define SVN_KEYWORD_HEADER "Header"
+
/** @} */
Index: subversion/libsvn_subr/subst.c
===================================================================
- --- subversion/libsvn_subr/subst.c (revision 10373)
+++ subversion/libsvn_subr/subst.c (working copy)
@@ -183,6 +183,19 @@
human_date ? human_date : "",
author ? author : "");
}
+ else if ((! strcasecmp (keyword, SVN_KEYWORD_HEADER)))
+ {
+ const char *human_date = NULL;
+
+ if (date)
+ SVN_ERR (date_prop_to_human (&human_date, FALSE, date, pool));
+
+ kw->header = svn_string_createf (pool, "%s %s %s %s",
+ (url ? url : ""),
+ rev,
+ human_date ? human_date : "",
+ author ? author : "");
+ }
}
return SVN_NO_ERROR;
@@ -420,6 +433,16 @@
return TRUE;
}
+ /* Header */
+ if (keywords->header)
+ {
+ if (translate_keyword_subst (buf, len,
+ SVN_KEYWORD_HEADER,
+ (sizeof (SVN_KEYWORD_HEADER)) - 1,
+ expand ? keywords->header : NULL))
+ return TRUE;
+ }
+
/* No translations were successful. Return FALSE. */
return FALSE;
}
Index: subversion/clients/cmdline/main.c
===================================================================
- --- subversion/clients/cmdline/main.c (revision 10373)
+++ subversion/clients/cmdline/main.c (working copy)
@@ -520,6 +520,7 @@
" Id - A compressed summary of the "
"previous\n"
" 4 keywords.\n"
+ " Header - Same as Id but with full file URL\n"
" svn:executable - If present, make the file executable. This\n"
" property cannot be set on a directory. A non-recursive "
"attempt\n"
Index: subversion/tests/libsvn_wc/translate-test.c
===================================================================
- --- subversion/tests/libsvn_wc/translate-test.c (revision 10373)
+++ subversion/tests/libsvn_wc/translate-test.c (working copy)
@@ -281,6 +281,7 @@
keywords.author = author ? svn_string_create (author, pool) : NULL;
keywords.url = url ? svn_string_create (url, pool) : NULL;
keywords.id = NULL;
+ keywords.header = NULL;
err = svn_subst_copy_and_translate (src_fname, dst_fname, dst_eol, repair,
&keywords, expand, pool);
- --
Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P. 424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/l6aqG7NDYQkJwERAuNAAJ9teC2b23HEVQsuNQ32Nq0519vDpgCgh96f
+/FUZEHXCLGGs5GTStDtPgQ=
=Ilr2
-----END PGP SIGNATURE-----
Re: PATCH: $Header$ handling + existing (behaviour) of $HeadURL$
now also in $Header$?
Posted by John Peacock <jp...@rowman.com>.
C.A.T.Magic wrote:
> If its critical to regenerate 100% identical files,
> there is probably only one solution:
> tag, delete_wc / fresh checkout tag, build, release it.
>
I would actually say
tag, export, build, test, release
would be the most appropriate workflow.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling + existing (behaviour) of $HeadURL$
now also in $Header$?
Posted by "C.A.T.Magic" <c....@gmx.at>.
John Peacock wrote:
>
> You misunderstand how keywords work in general. The client code only
> interprets a keyword at the point in time the file is changed (either
> through an update, checkout, or export). There is no code that walks
> through the WC and re-expands keywords based on some external event _if
> the file itself hasn't been changed_.
I absolutely understand _why_ it is the way it is
(mostly speed reasons)
but it means that one gets slightly different files,
dependent on the method used to checkout a WC.
at least 3 methods:
-) fresh checkout trunk at revision x
would contain "/trunk/foo"
-) fresh checkout a tag of that trunk revision x
would contain "/trunk/tag/foo"
-) checkout trunk and switch to that tag
would contain either "/trunk/tagxyz/foo"
or "/trunk/foo" depending on the WC's
prevous content.
If its critical to regenerate 100% identical files,
there is probably only one solution:
tag, delete_wc / fresh checkout tag, build, release it.
:-)
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling + existing BUG of $HeadURL$ now also
in $Header$?
Posted by John Peacock <jp...@rowman.com>.
C.A.T.Magic wrote:
> but there is also a negative side to using $Header$ in SVN:
> because $Header$ alsways contains the full repository path,
> it is also containing the 'TAG' path.
> $Header: /Tags/foo-20040501/test.txt,v 5 2004/07/22 16:39:38 cat Exp $
> $Header: /Tags/foo-20040608/test.txt,v 8 2004/07/22 16:39:38 cat Exp $
>
> this means that you get different file content for _all_ files,
> dependent on the tag you used to checkout the file,
> even if the rest of the file is identical.
That's a feature, not a bug. If you export from a tag, any keywords which
reflect the path in the repository must display the current location in the
repository, regardless of whether the file has changed from wherever it was
copied from (TRUNK is not special in this regard).
> In CVS the path and version always remains the same if the file is
> unmodified.
And that's *loss* of information.
>
>
> does this patch ensure that svn switch visits ALL files containing
> $Header$ and update them correctly?
You misunderstand how keywords work in general. The client code only interprets
a keyword at the point in time the file is changed (either through an update,
checkout, or export). There is no code that walks through the WC and re-expands
keywords based on some external event _if the file itself hasn't been changed_.
> #>cat file.txt
> $HeadURL: file:///Repos/file.txt $
>
> #>svn switch file:///Repos/TAG/file.txt file.txt
>
> #>cat file.txt
> $HeadURL: file:///Repos/file.txt $
>
> ^^^^ but this should now be Repos/TAG/ !
'switch' does not imply 'update' here; the file hasn't changed between TRUNK and
TAG, so the client does not update the file (i.e. re-expand the keywords).
>
> #>del file.txt
> #>svn update file.txt
> #>type file.txt
> $HeadURL: file:///Repos/TAG/file.txt $
>
> ^^^^ only works if file is deleted first.
Now you have forced the client to regenerate the keyword (by deleting the file).
'svn up' is not sufficient on it's own to regenerate keywords; whether it
should be is a matter of debate. I'm incline to think it should, but that might
entail much more client-side activity than would seems fruitful.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling + existing BUG of $HeadURL$ now also
in $Header$?
Posted by "C.A.T.Magic" <c....@gmx.at>.
Alexander L. Belikoff wrote:
> $Header$ has very clear advantages over $Id$.
in SVN, the $Id$ keyword has lost a bit of information
in comparison to CVS: the _branch_ of the file.
SVN:
$Id: file.txt 2 2004-07-22 16:22:50Z cat $
CVS:
$Id: file,v 1.259.2.2 2003/12/04 20:38:11 cat Exp $
in svn's $Id$ its hard (or impossible?) to tell if
the file came from trunk or from a branch.
in cvs it is clearly visibly because you see
the 4-digit version number "1.259.2.2".
but there is also a negative side to using $Header$ in SVN:
because $Header$ alsways contains the full repository path,
it is also containing the 'TAG' path.
$Header: /Tags/foo-20040501/test.txt,v 5 2004/07/22 16:39:38 cat Exp $
$Header: /Tags/foo-20040608/test.txt,v 8 2004/07/22 16:39:38 cat Exp $
this means that you get different file content for _all_ files,
dependent on the tag you used to checkout the file,
even if the rest of the file is identical.
In CVS the path and version always remains the same if the file is
unmodified.
does this patch ensure that svn switch visits ALL files containing
$Header$ and update them correctly?
$HeadURL$ is already buggy in this regard:
( the following assumes Repos/file.txt and
a tag created from it as Repos/TAG/file.txt
exists )
#>cat file.txt
$HeadURL: file:///Repos/file.txt $
#>svn switch file:///Repos/TAG/file.txt file.txt
#>cat file.txt
$HeadURL: file:///Repos/file.txt $
^^^^ but this should now be Repos/TAG/ !
#>del file.txt
#>svn update file.txt
#>type file.txt
$HeadURL: file:///Repos/TAG/file.txt $
^^^^ only works if file is deleted first.
======
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: different output of svn status and svnversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Johannes Fahrenkrug wrote:
> When I run »svn status« I get
> At revision 256
'svn status' never prints that phrase, nor does it try to summarize the
overall mixture of revisions in a working copy the way 'svnversion' does.
'svn status -u' will print the latest revision in the repository:
"Status against revision: XXXX". Perhaps that's what you're remembering?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
different output of svn status and svnversion
Posted by Johannes Fahrenkrug <jf...@gebeco.de>.
Hi,
I've got a problem: We have a relatively big working copy and a tiny
script that writes
the output of svnversion into a file.
When I run »svn status« I get
At revision 256
When I run svnversion I get
252:254
How can it be that svn status is convinced that the working copy is at
revision 256 and
that svnversion is convinced that it's a mixed working copy of
revision 252 and 254?
hmmmmmm...
-Johannes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling
Posted by John Peacock <jp...@rowman.com>.
Alexander L. Belikoff wrote:
> I think the next serious step in the keyword business would be the
> implementation of the custom keywords.
As I may have already suggested, I've been working on just that:
http://subversion.tigris.org/issues/show_bug.cgi?id=890
The problem with custom keywords is that there is no facility in Subversion
[currently] to store repository preferences on the server and communicate them
to the client. Hence, how do you define custom keywords without compiling them
into the binary?
See also my recent posting about inherited properties, which may be the best way
to handle this dilemma.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling
Posted by "Alexander L. Belikoff" <ab...@vallinor4.com>.
On Wednesday 21 July 2004 22:05, John Peacock wrote:
>
> I'm not saying that $Header$ isn't useful, just that the number of people
> who have been asking for it is not as significant as other CVS keywords
> (specifically $Log$, which is _not_ going to be supported).
<shudder> $Log$ was an abomination even in RCS. I am yet to hear a
constructive reason for using it (a lot of our legacy code has it - imagine
some foo.c at revision 1.632 with $Log$ inside). Considering how non-trivial
it would be to implement it *correctly*, I'd rather see those cycles going
towards the better merge facility rather than $Log$.
I think the next serious step in the keyword business would be the
implementation of the custom keywords. That would be invaluable for the
environments with multiple source control systems. I am aware of one team
using hacked SVN that implements an SvnId keyword, that works exactly like
$Id$ just to have that one preserved when they promote their team code to the
global RCS repository. These things should be solved on a more generic level.
--
Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P. 424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling
Posted by John Peacock <jp...@rowman.com>.
Alexander L. Belikoff wrote:
> I disagree. While I am not sure what "CVS methodology" you have in mind,
> $Header$ has very clear advantages over $Id$.
I'm sorry, I think I got you confused with the other two posters who were
discussing $Header$. What they were describing was using the $Header$ to
generate file-by-file reports for changes between releases (the CVS way),
instead of diff between the release tags for actual log entries (the Subversion
way).
> 3. I actually like $Header$ :-) It crams more useful information into the
> string compared to $Id$.
I'm not saying that $Header$ isn't useful, just that the number of people who
have been asking for it is not as significant as other CVS keywords
(specifically $Log$, which is _not_ going to be supported).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling
Posted by "Alexander L. Belikoff" <ab...@vallinor4.com>.
On Wednesday 21 July 2004 09:52, John Peacock wrote:
> I've been closely watching the keyword topic since I joined the list
> (and have a patch in process to change the keyword handling completely),
> and I have to say that $Header$ has not been that highly demanded (no
> offense intended). As I suggested in your original thread, the use of
> $Header$ to create reports is trying to map CVS methodology to Subversion.
I disagree. While I am not sure what "CVS methodology" you have in mind,
$Header$ has very clear advantages over $Id$.
1. A lot of projects use both interchangeably in CVS and RCS. Supporting
$Header$ would prevent an effort of turining $Header$ into $Id$
2. $Header$ allows the programmer to see exactly where a certain file comes
from. This is invaluable when analyzing the executable. You won't believe how
many times in my practice I saw people scratching their head when seeing two
or more different Id strings for the same filename. When you have a
production problem (which is usually the moment that calls for such
measures), having an additional clue is more than welcome.
3. I actually like $Header$ :-) It crams more useful information into the
string compared to $Id$.
> That being said, please read HACKING and include a log message in the
> project style so that this patch can be considered for adoption.
I am most definitely doing so now (who needs to RTFM *before* doing
something?!) ;-)
--
Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P. 424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling
Posted by John Peacock <jp...@rowman.com>.
Alexander L. Belikoff wrote:
> Attached (and included) is a patch implementing the RCS $Header$ keyword. A
> lot of people have been asking for this and quite a lot of people use it a
> lot.
I've been closely watching the keyword topic since I joined the list
(and have a patch in process to change the keyword handling completely),
and I have to say that $Header$ has not been that highly demanded (no
offense intended). As I suggested in your original thread, the use of
$Header$ to create reports is trying to map CVS methodology to Subversion.
That being said, please read HACKING and include a log message in the
project style so that this patch can be considered for adoption.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org