You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew McIntyre <mc...@gmail.com> on 2005/10/31 08:10:52 UTC
problem with svnversion -n
Hi subversion-users:
Recently Apache Derby hit an unusual problem with svnversion that I
think may be an svnversion bug. During Apache Gump's build of Derby,
which contains the Derby source code in a copied directory, Ant
records the output of 'svnversion -n .' to a file, which is later
read back in as an Ant property. Because this is not a checked-out
directory in the gump build, the version is reported as 'exported',
but with a newline attached.
Because this is later read back in as the version at which Derby was
built, and included in the manifest file for the Derby jar files,
this causes the generation of the Derby manifest file to fail because
the newline after 'exported' puts a newline into the manifest file in
an unacceptable location.
The problem appears to be in svnversion's main.c, line 287.
Perhaps:
SVN_INT_ERR (svn_cmdline_printf (pool, _("exported\n")));
should be:
SVN_INT_ERR (svn_cmdline_printf (pool, _((no_newline ?
"exported" : "exported\n"))));
Similar problem at line 296. Comments? If there's a workaround to
suppress the extra newline for exported directories, let me know.
Thanks,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: problem with svnversion -n
Posted by Andrew McIntyre <mc...@gmail.com>.
On Oct 31, 2005, at 1:48 AM, John Szakmeister wrote:
> On Monday 31 October 2005 03:10, Andrew McIntyre wrote:
>
>> The problem appears to be in svnversion's main.c, line 287.
>> Perhaps:
>> SVN_INT_ERR (svn_cmdline_printf (pool, _("exported\n")));
>> should be:
>> SVN_INT_ERR (svn_cmdline_printf (pool, _((no_newline ?
>> "exported" : "exported\n"))));
>
> What version are you using? I see this the 1.0.x and 1.1.x
> branches, but
> 1.2.x and 1.3.x look fine.
I was looking at version 1.1.4, the version currently in use with
Apache Gump.
>> Similar problem at line 296. Comments? If there's a workaround to
>> suppress the extra newline for exported directories, let me know.
>
> No, it's definitely a bug. However, Jani Averbach fixed it on
> trunk in
> r10987. It looks like it never made it to the 1.0.x and 1.1.x
> branches
> though.
>
Yep, I hadn't checked the 1.2.x code. It is fixed there. Thanks for
the pointer!
> I could not find anything wrong near line 296. The only thing I
> saw was a
> line printing an error to stderr, and the newline is correct in
> that case.
I was referring to:
svn_clear_error (svn_cmdline_fprintf (stderr, pool,
_("'%s' not versioned, and not
exported\n"),
wc_path));
As you suggested, the newline is acceptable in this case since it is
printed to stderr.
Thanks again, I'll recommend upgrading to the 1.2.x line to the Gump
folks.
Cheers,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: problem with svnversion -n
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 31 October 2005 03:10, Andrew McIntyre wrote:
> Hi subversion-users:
>
> Recently Apache Derby hit an unusual problem with svnversion that I
> think may be an svnversion bug. During Apache Gump's build of Derby,
> which contains the Derby source code in a copied directory, Ant
> records the output of 'svnversion -n .' to a file, which is later
> read back in as an Ant property. Because this is not a checked-out
> directory in the gump build, the version is reported as 'exported',
> but with a newline attached.
>
> Because this is later read back in as the version at which Derby was
> built, and included in the manifest file for the Derby jar files,
> this causes the generation of the Derby manifest file to fail because
> the newline after 'exported' puts a newline into the manifest file in
> an unacceptable location.
>
> The problem appears to be in svnversion's main.c, line 287.
> Perhaps:
> SVN_INT_ERR (svn_cmdline_printf (pool, _("exported\n")));
> should be:
> SVN_INT_ERR (svn_cmdline_printf (pool, _((no_newline ?
> "exported" : "exported\n"))));
What version are you using? I see this the 1.0.x and 1.1.x branches, but
1.2.x and 1.3.x look fine. There will not be another release on the 1.0.x
line unless a security bug is found, and 1.1.x is quickly approaching that
same point since 1.3.0 is around the corner.
> Similar problem at line 296. Comments? If there's a workaround to
> suppress the extra newline for exported directories, let me know.
No, it's definitely a bug. However, Jani Averbach fixed it on trunk in
r10987. It looks like it never made it to the 1.0.x and 1.1.x branches
though.
I could not find anything wrong near line 296. The only thing I saw was a
line printing an error to stderr, and the newline is correct in that case.
I'd recommend upgrading to 1.2.3 or 1.3.0 (when it becomes available).
Thanks for the report!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org