"missing" feature

[Svenne Krap <sv...@krap.dk>]

Hi folks.

I think I have a suggest for a very nice feature:

Having a LaTeX document with multiple source files (included into one 
main document), I really would like to have a keyword, that would be the 
greatest revision of the document. I.e.

consider the following in the WC:

main.tex (revision 12)
include1.tex (revision 18)
include2.tex (revision 4)
include3.tex (revision 35)

Now I would like to add a header to every page telling, that the 
document is built upon revision 35.

I can't find anything like that in the documentation...

Svenne

Re: "missing" feature

[Richard Lewis <rt...@jabble.com>]

Svenne Krap <sv...@krap.dk> writes:

> A whole tree might be a "single file" (or unit) logically (for example
> LaTeX documents, or perhaps a PHP website - not everything uses/has a
> build system)

For LaTeX, the `build system' is the running of latex (and friends),
so you could have something like

\immediate\write18{%
  echo "\string\newcommand{\string\version}{`/usr/bin/svnversion .`}" > ./ver.tex
}
\input{./ver.tex}

at the top of your main document, and then \version will give you the
output of svnversion (don't forget to give latex the --shell-escape
option to enable \write18)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: "missing" feature

[Glen <gl...@model3.net>]

Not sure if this will help or not as I have never used it personally.

There is a small utility called SubWCRev.exe in the tortoisesvn website 
http://tortoisesvn.tigris.org/download.html   

Here is the text from the website about it.

SubWCRev.exe: a small command line tool which you can use in your build 
steps. It takes a file as an argument and replaces all "$WCREV$" strings 
with the revision of your working copy. This is usefull if you want to 
include the Subversion revision in the version of your project. If you 
need an example, check out the TortoiseSVN source.




Max Bowsher wrote:

>>>>Max Bowsher wrote:
>>>>        
>>>>
>>>>>svnversion.
>>>>>          
>>>>>
>>>Svenne Krap wrote:
>>>      
>>>
>>>>Is there any way to use that like a keyword ?
>>>>        
>>>>
>>Max Bowsher wrote:
>>    
>>
>>>No. Because when you really start analysing the problem, you realize that
>>>this piece of information is very un-keyword-like. Principally in that it
>>>      
>>>
>is
>  
>
>>>information about a *tree* not a single file.
>>>      
>>>
>
>Svenne Krap wrote:
>  
>
>>I really don't see how this belonging to a tree makes it less
>>keyword-like. Why hasn't it been implemented as (say) $ TreeRevision: $
>>then ?
>>    
>>
>
>Because doing so would require a major alteration to the way subversion
>handles working copies.
>After any update/switch/checkout operation, subversion would need to recurse
>both down and *up* through the directory structure seeking files with
>svn:keywords containing TreeRevision - *even* if the update was just on a
>single file. The cost of this is deemed unacceptable.
>
>  
>
>>I frankly never understood the rationale for having mixed
>>revisionnumbers in a WC,
>>    
>>
>
>"svn up" in a subdirectory, to save time, when you only need to update the
>part you are working on.
>
>"svn switch" of a part of a working copy, when you want to work on a certain
>module of code, whilst continuing to track the trunk for other modules.
>
>"svn up -r oldrev program" to run the current testsuite against an old
>program version, to verify that the tests are detecting the old bugs
>correctly.
>
>"svn ci file1" when someone else has modified and committed some other file
>meanwhile. If subversion couldn't represent mixed revision WCs, it would
>have to force you to update your entire WC to HEAD before allowing you to
>commit *anything*.
>
>  
>
>>for me, the revisionnumber shows the version of
>>the "package" not the file.
>>    
>>
>
>A revision number does indicate the version of the "package". And the
>package version a file last changed in is a convenient way to label a
>particular version of a file.
>
>  
>
>>I actually think the "*Global Revision
>>Numbers"* part of the SVNBook agrees with me here... I might be sleepy
>>right now (it's bedtime soon), but is you rationale for not having this
>>"treerevision" not directly contradictionary to the whole idea of global
>>revision numbers ? Let me quote the SVNbook "Subversion's revision
>>numbers apply to /entire trees/, not individual files", that tells me
>>there should be a way to get the current revision of the file (not the
>>latest revision, where this file was modified).
>>    
>>
>
>You can get the current revision of a file (svn info), but there is
>absolutely no guarantee that it means anything about the state of the tree,
>for reasons given above.
>
>
>Max.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>  
>

Re: "missing" feature

[Max Bowsher <ma...@ukf.net>]

>>> Max Bowsher wrote:
>>>> svnversion.
>>
>> Svenne Krap wrote:
>>> Is there any way to use that like a keyword ?
>
> Max Bowsher wrote:
>> No. Because when you really start analysing the problem, you realize that
>> this piece of information is very un-keyword-like. Principally in that it
is
>> information about a *tree* not a single file.

Svenne Krap wrote:
> I really don't see how this belonging to a tree makes it less
> keyword-like. Why hasn't it been implemented as (say) $ TreeRevision: $
> then ?

Because doing so would require a major alteration to the way subversion
handles working copies.
After any update/switch/checkout operation, subversion would need to recurse
both down and *up* through the directory structure seeking files with
svn:keywords containing TreeRevision - *even* if the update was just on a
single file. The cost of this is deemed unacceptable.

> I frankly never understood the rationale for having mixed
> revisionnumbers in a WC,

"svn up" in a subdirectory, to save time, when you only need to update the
part you are working on.

"svn switch" of a part of a working copy, when you want to work on a certain
module of code, whilst continuing to track the trunk for other modules.

"svn up -r oldrev program" to run the current testsuite against an old
program version, to verify that the tests are detecting the old bugs
correctly.

"svn ci file1" when someone else has modified and committed some other file
meanwhile. If subversion couldn't represent mixed revision WCs, it would
have to force you to update your entire WC to HEAD before allowing you to
commit *anything*.

> for me, the revisionnumber shows the version of
> the "package" not the file.

A revision number does indicate the version of the "package". And the
package version a file last changed in is a convenient way to label a
particular version of a file.

> I actually think the "*Global Revision
> Numbers"* part of the SVNBook agrees with me here... I might be sleepy
> right now (it's bedtime soon), but is you rationale for not having this
> "treerevision" not directly contradictionary to the whole idea of global
> revision numbers ? Let me quote the SVNbook "Subversion's revision
> numbers apply to /entire trees/, not individual files", that tells me
> there should be a way to get the current revision of the file (not the
> latest revision, where this file was modified).

You can get the current revision of a file (svn info), but there is
absolutely no guarantee that it means anything about the state of the tree,
for reasons given above.


Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: "missing" feature

[Svenne Krap <sv...@krap.dk>]

I really don't see how this belonging to a tree makes it less 
keyword-like. Why hasn't it been implemented as (say) $ TreeRevision: $ 
then ?
A whole tree might be a "single file" (or unit) logically (for example 
LaTeX documents, or perhaps a PHP website - not everything uses/has a 
build system)
Especially the SVNParentPath directive for Apache2 kinda encourages to 
use a lot of repositories this style (at least for me :)

I frankly never understood the rationale for having mixed 
revisionnumbers in a WC, for me, the revisionnumber shows the version of 
the "package" not the file. I actually think the "*Global Revision 
Numbers"* part of the SVNBook agrees with me here... I might be sleepy 
right now (it's bedtime soon), but is you rationale for not having this 
"treerevision" not directly contradictionary to the whole idea of global 
revision numbers ? Let me quote the SVNbook "Subversion's revision 
numbers apply to /entire trees/, not individual files", that tells me 
there should be a way to get the current revision of the file (not the 
latest revision, where this file was modified).

Svenne

Max Bowsher wrote:

>>Max Bowsher wrote:
>>    
>>
>>>svnversion.
>>>      
>>>
>
>Svenne Krap wrote:
>  
>
>>Is there any way to use that like a keyword ?
>>    
>>
>
>No. Because when you really start analysing the problem, you realize that
>this piece of information is very un-keyword-like. Principally in that it is
>information about a *tree* not a single file.
>
>  
>
>>Or any fancy way to include that automaticly ?
>>    
>>
>
>Use it in your build system.
>
>Max.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>  
>

Re: "missing" feature

[Max Bowsher <ma...@ukf.net>]

> Max Bowsher wrote:
>> svnversion.

Svenne Krap wrote:
> Is there any way to use that like a keyword ?

No. Because when you really start analysing the problem, you realize that
this piece of information is very un-keyword-like. Principally in that it is
information about a *tree* not a single file.

> Or any fancy way to include that automaticly ?

Use it in your build system.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: "missing" feature

[Svenne Krap <sv...@krap.dk>]

Is there any way to use that like a keyword ? Or any fancy way to 
include that automaticly ?

Max Bowsher wrote:

>Svenne Krap wrote:
>  
>
>>Hi folks.
>>
>>I think I have a suggest for a very nice feature:
>>
>>Having a LaTeX document with multiple source files (included into one
>>main document), I really would like to have a keyword, that would be the
>>greatest revision of the document. I.e.
>>
>>consider the following in the WC:
>>
>>main.tex (revision 12)
>>include1.tex (revision 18)
>>include2.tex (revision 4)
>>include3.tex (revision 35)
>>
>>Now I would like to add a header to every page telling, that the
>>document is built upon revision 35.
>>
>>I can't find anything like that in the documentation...
>>    
>>
>
>svnversion.
>
>
>Max.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>  
>

Re: "missing" feature

[Max Bowsher <ma...@ukf.net>]

Svenne Krap wrote:
> Hi folks.
> 
> I think I have a suggest for a very nice feature:
> 
> Having a LaTeX document with multiple source files (included into one
> main document), I really would like to have a keyword, that would be the
> greatest revision of the document. I.e.
> 
> consider the following in the WC:
> 
> main.tex (revision 12)
> include1.tex (revision 18)
> include2.tex (revision 4)
> include3.tex (revision 35)
> 
> Now I would like to add a header to every page telling, that the
> document is built upon revision 35.
> 
> I can't find anything like that in the documentation...

svnversion.


Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org