subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Shahaf" <...@daniel.shahaf.name>
Subject Re: Unexpected behavior of svn log -r BASE:HEAD
Date Thu, 03 Jun 2021 20:45:06 GMT
Yasuhito FUTATSUKI wrote on Thu, 03 Jun 2021 04:25 +00:00:
> In article <CAFJ3QW+sM2_d4a2ELX1pJCphUWR4a_nh5+bVrx4CDF_iVvALdg@mail.gmail.com>
> guillaume.brunerie@gmail.com writes:
> > Den ons 2 juni 2021 12:47Yasuhito FUTATSUKI <futatuki@yf.bsdclub.org> skrev:
> > Ah, thank you, I guess the help message should be fixed then?
> 
> I have no idea about how accurate it should be in example section,

I think examples should be more accurate than this example is.

> and I can't also propose how it should be because of my poor English
> writing ability. However if you have some idea how it should be,
> please make a draft (or patch against subversion/svn/svn.c).

Seconded. :)

We could, say, have the help text point out that rBASE itself may or may
not be included in the output; or perhaps we could change the example to
one that can be explained without branches [in the CPU execution sense
of the word].

> > Is there another way to get what is described in the help message? To show
> > the log messages for any incoming changes to foo.c during the next 'svn
> > update'. This is exactly what I was trying to do.
> 
> One of obvious way is something like this (although this can't take
> multiple target paths):
> [[[
> #!/bin/sh
> 
> # if This is not in your command search paths, please change it.
> svn=svn
> 

This would break «svn=/path/to/svn /path/to/this-script».  Instead:

    : ${svn:=svn}

> revision_base=`${svn} info -r BASE --show-item revision "$1"` || exit $?
> revision_head=`${svn} info -r HEAD --show-item revision "$1"` || exit $?
> 

Recommend to add a «--» guard at the end of options.

Recommend to use peg rather than operative revisions.  Doesn't make a
difference for the first line, but I think it does make a difference for
the second line (it would have to check that $1@HEAD and $1@BASE are the
same node-id).

> # This check is needed to avoid "No such revision error" 
> if test "${revision_base}" = "${revision_head}" ; then exit 0; fi
> 
> ${svn} log -r $((${revision_base}+1)):HEAD --incremental "$1"

Race condition: by the time this command is run, a commit might have
been made, in which case HEAD could be equal to revision_base+1, or even
greater than it.  Recommend s/HEAD/${revision_head}/.

> ]]]

> or check the BASE revision number in advance and filter out the log
> on its revision number from the result of 'svn log -r BASE:HEAD'.

FWIW, one way to implement this is to use «svn log --xml», filter that,
and then synthesize to XML to plain «svn log» output in the same way
https://subversion.apache.org/docs/release-notes/#upcoming-patch-release
does (there's a link at the end of that to the Python implementation).

Aside: Looking at that section, it looks like it's time to release a 1.14.2.

> In addition, to get "exactly" what you want, you need forbidding
> everyone to commit change on the target path just after you examine
> the HEAD revision until you run 'svn update', and I think it is not
> good idea.

It's easier is to make note of the numeric value of HEAD and then run
«svn up -r N» to update precisely to that.  Compare
tools/dist/release.py:bump_versions_on_branch()'s use of HEAD in
a similar situation involving commits rather than updates.

Cheers,

Daniel

Mime
View raw message