Renaming an external directory

[Markus Schaber]

Hi,

 

As "svn rename" fails to rename external directories, I currently use
the following "workaround":

-  Rename the directory directly on the file system.

-  Change the externals definition in the containing directory
to point to the new destination.

 

Is this mechanism safe to use with SVN 1.6?

 

Best regards

Markus Schaber

___

We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com   |
Web: http://www.3s-software.com  
CoDeSys internet forum: http://forum.3s-software.com
 
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 

 

Re: Renaming an external directory

[Ryan Schmidt]

On May 13, 2011, at 02:00, Markus Schaber wrote:

> As „svn rename“ fails to rename external directories, I currently use the 
> following „workaround“:
> -  Rename the directory directly on the file system.
> -  Change the externals definition in the containing directory to 
> point to the new destination.
>  
> Is this mechanism safe to use with SVN 1.6? 

That sounds like the way to do it, yes.

SVN Commit Error (svn: database is locked)

[朱苗]

Hi Dear,
 
   I'm using SVN 1.6.15 as my svn server (installed in SUSE 10).
 
   I can checkout, update, commit, import to my svn repositories successfully.
 
   But today, I suffered the error when doing svn commit:
 
   =
   svn: Commit failed (details follow): 
   svn: database is locked 
  ==
 
   The case is that I run the "svn commit" task at the same time in several 
threads. And in each thread, the script runs 2 tasks:
 
   #!/usr/bin/bash
   svn ci -m "new file1" file1
   svn ci -m "new file2" file2
 
   After I changed the script to:
 
   #!/usr/bin/bash
   svn ci -m "new files" 
 
   The error above not happen again.
   
   It was OK when I run in my old SVN server (svn version is 1.5.4). But it 
happen in 1.6.15 if I use the 1st script.
 
   Is it still a bug? Or is there any way I can resolve the problem? Is there 
any stable version that has the bug fixed?
 
   Thanks!
 
BR//Zoe
  

Detect incompatible (future) workingcopy format.

[Markus Schaber]

Hi,

What is the safest future-compatible way to check for an incompatible /
unknown working copy format which was written by a future subversion
version? (e. G. WC-NG by SVN 1.7?)

My idea was to run status with depth=empty on the workingcopy root, and
check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code.

Is there a function specifically designed for this purpose?

Regards,
Markus

Help with constant conflicts

[K.L.]

Hi,

Having problems with merge.


me@localhost /srv/www $ svn ls svn+ssh://example.com/var/svn/svnbugs
me@localhost /srv/www $ svn mkdir svn+ssh://example.com/var/svn/svnbugs/trunk

Log message unchanged or not specified
(a)bort, (c)ontinue, (e)dit:
c

Committed revision 1.
me@localhost /srv/www $ svn ls svn+ssh://example.com/var/svn/svnbugs
trunk/
me@localhost /srv/www $ svn mkdir svn+ssh://example.com/var/svn/svnbugs/branches

Log message unchanged or not specified
(a)bort, (c)ontinue, (e)dit:
c

Committed revision 2.
me@localhost /srv/www $ svn ls svn+ssh://example.com/var/svn/svnbugs
branches/
trunk/
me@localhost /srv/www $ svn co svn+ssh://example.com/var/svn/svnbugs
Asvnbugs/trunk
Asvnbugs/branches
Checked out revision 2.
me@localhost /srv/www $ cd svnbugs/
me@localhost /srv/www/svnbugs $ ls -la
total 20
drwxr-xr-x  5 me me 4096 May 13 13:26 .
drwxrwxrwx 26 me wheel 4096 May 13 13:26 ..
drwxr-xr-x  6 me me 4096 May 13 13:26 .svn
drwxr-xr-x  3 me me 4096 May 13 13:26 branches
drwxr-xr-x  3 me me 4096 May 13 13:26 trunk
me@localhost /srv/www/svnbugs $ mkdir trunk/dir1
me@localhost /srv/www/svnbugs $ svn st
?   trunk/dir1
me@localhost /srv/www/svnbugs $ svn add trunk/dir1/
A trunk/dir1
me@localhost /srv/www/svnbugs $ svn commit -m "" trunk/dir1/
Adding trunk/dir1

Committed revision 3.
me@localhost /srv/www/svnbugs $ svn cp
svn+ssh://example.com/var/svn/svnbugs/trunk
svn+ssh://example.com/var/svn/svnbugs/branches/branch1

Log message unchanged or not specified
(a)bort, (c)ontinue, (e)dit:
c

Committed revision 4.
me@localhost /srv/www/svnbugs $ svn up
Abranches/branch1
Abranches/branch1/dir1
Updated to revision 4.
me@localhost /srv/www/svnbugs $ mkdir trunk/dir2
me@localhost /srv/www/svnbugs $ svn st
?   trunk/dir2
me@localhost /srv/www/svnbugs $ svn add trunk/dir2
A trunk/dir2
me@localhost /srv/www/svnbugs $ svn commit -m "" trunk/dir2
Adding trunk/dir2

Committed revision 5.
me@localhost /srv/www/svnbugs $ cd branches/branch1/
me@localhost /srv/www/svnbugs/branches/branch1 $ svn st
me@localhost /srv/www/svnbugs/branches/branch1 $ svn up
At revision 5.
me@localhost /srv/www/svnbugs/branches/branch1 $ svn merge
svn+ssh://example.com/var/svn/svnbugs/trunk
--- Merging r4 through r5 into '.':
Adir2
me@localhost /srv/www/svnbugs/branches/branch1 $ svn st
 M  .
A  +dir2
me@localhost /srv/www/svnbugs/branches/branch1 $ svn commit -m "merged @5"
Sendingbranch1
Adding branch1/dir2

Committed revision 6.
me@localhost /srv/www/svnbugs/branches/branch1 $ svn st
me@localhost /srv/www/svnbugs/branches/branch1 $ svn up
At revision 6.
me@localhost /srv/www/svnbugs/branches/branch1 $ ls
dir1  dir2
me@localhost /srv/www/svnbugs/branches/branch1 $ mkdir dir3
me@localhost /srv/www/svnbugs/branches/branch1 $ ls
dir1  dir2  dir3
me@localhost /srv/www/svnbugs/branches/branch1 $ svn st
?   dir3
me@localhost /srv/www/svnbugs/branches/branch1 $ svn add dir3
A dir3
me@localhost /srv/www/svnbugs/branches/branch1 $ svn commit -m "" dir3
Adding dir3

Committed revision 7.
me@localhost /srv/www/svnbugs/branches/branch1 $ cd ..
me@localhost /srv/www/svnbugs/branches $ cd ../trunk/
me@localhost /srv/www/svnbugs/trunk $ svn merge
svn+ssh://example.com/var/svn/svnbugs/branches/branch1
--- Merging r4 through r7 into '.':
   C dir2
Adir3
Summary of conflicts:
  Tree conflicts: 1
me@localhost /srv/www/svnbugs/trunk $ svn st
 M  .
  C dir2
  >   local add, incoming add upon merge
A  +dir3



The same thing happens upon file operations as well on ubuntu, osx, gentoo.


server


# uname -a
Linux example.com 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010
x86_64 GNU/Linux
# svn --version
svn, version 1.6.16 (r1073529)
   compiled May  1 2011, 01:56:39
# aptitude show subversion
Package: subversion
State: installed
Automatically installed: no
Version: 1.6.16dfsg-1+b1
Priority: optional
Section: vcs
Maintainer: Peter Samuelson 
Uncompressed Size: 4,399 k
Depends: libsvn1 (= 1.6.16dfsg-1+b1), libapr1 (>= 1.2.7), libc6 (>=
2.3), libsasl2-2
Suggests: subversion-tools, db4.8-util, patch


client


# uname -a
Linux localhost 2.6.36-gentoo-r5 #1 SMP Fri Feb 18 15:24:49 EET 2011
x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux
# svn --version
svn, version 1.6.16 (r1073529)
   compiled May 13 2011, 13:25:25
# emerge --info dev-vcs/subversion
Portage 2.1.9.42 (default/linux/amd64/10.0/desktop/kde, gcc-4.4.5,
libc-0-r0, 2.6.36-gentoo-r5 x86_64)
=
System Settings
=
System uname: 
Linux-2.6.36-gentoo-r5-x86_64-AMD_Phenom-tm-_II_X4_965_Processor-with-gentoo-2.0.2
Timestamp of tree: Fri, 13 May 2011 09:45:01 +
app-shells/bash: 4.1_p9
dev-java/java-config: 2.1.11-r3
dev-lang/python: 2.7.1-r1, 3.1.3-r1
dev-util/cmake:  

Re: Detect incompatible (future) workingcopy format.

[Erik Huelsmann]

Hi Markus,

On Fri, May 13, 2011 at 11:20 AM, Markus Schaber
 wrote:
> Hi,
>
> What is the safest future-compatible way to check for an incompatible /
> unknown working copy format which was written by a future subversion
> version? (e. G. WC-NG by SVN 1.7?)
>
> My idea was to run status with depth=empty on the workingcopy root, and
> check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code.
>
> Is there a function specifically designed for this purpose?

No. The current library functions are forward compatible for the
entire 1.x range. The working copy storage is considered to be an
internal artifact, meaning you're supposed to use the libraries (e.g.
through the python bindings) to access the working copy data.


Why do you want to know if a working copy changed its storage type?


Bye,

Erik.

Re: Detect incompatible (future) workingcopy format.

[Les Mikesell]

On 5/13/11 7:30 AM, Erik Huelsmann wrote:




What is the safest future-compatible way to check for an incompatible /
unknown working copy format which was written by a future subversion
version? (e. G. WC-NG by SVN 1.7?)

My idea was to run status with depth=empty on the workingcopy root, and
check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code.

Is there a function specifically designed for this purpose?


No. The current library functions are forward compatible for the
entire 1.x range. The working copy storage is considered to be an
internal artifact, meaning you're supposed to use the libraries (e.g.
through the python bindings) to access the working copy data.


Doesn't that assume that there is only one version of the library that can 
access a working copy location or at least that the versions only go forward 
over time?  There are a large number of ways that assumption can be wrong.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Help with constant conflicts

[Stephen Butler]

On May 13, 2011, at 13:41 , K.L. wrote:

> Hi,
> 
> Having problems with merge.

[...]

> me@localhost /srv/www/svnbugs/branches/branch1 $ svn merge
> svn+ssh://example.com/var/svn/svnbugs/trunk
> --- Merging r4 through r5 into '.':
> Adir2

[...]

> me@localhost /srv/www/svnbugs/trunk $ svn merge
> svn+ssh://example.com/var/svn/svnbugs/branches/branch1
> --- Merging r4 through r7 into '.':
>   C dir2
> Adir3
> Summary of conflicts:
>  Tree conflicts: 1
> me@localhost /srv/www/svnbugs/trunk $ svn st
> M  .
>  C dir2
>>  local add, incoming add upon merge
> A  +dir3

[...]

> Is it a bug or we issue wrong commands?
> 

The second merge was wrong.  To merge branch1 changes back to 
the trunk, use 'merge --reintegrate ^/branches/branch1'. 

See the section "Reintegrating a branch" in the SVN Book:

  
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Regards,
Steve

--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

AW: Detect incompatible (future) workingcopy format.

[Markus Schaber]

Hi, Erik,

> Von: Erik Huelsmann [mailto:ehu...@gmail.com]
> 
> Hi Markus,
> 
> On Fri, May 13, 2011 at 11:20 AM, Markus Schaber  software.com> wrote:
> > Hi,
> >
> > What is the safest future-compatible way to check for an incompatible
> > / unknown working copy format which was written by a future subversion
> > version? (e. G. WC-NG by SVN 1.7?)
> >
> > My idea was to run status with depth=empty on the workingcopy root,
> > and check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code.
> >
> > Is there a function specifically designed for this purpose?
> 
> No. The current library functions are forward compatible for the entire
> 1.x range. The working copy storage is considered to be an internal
> artifact, meaning you're supposed to use the libraries (e.g.
> through the python bindings) to access the working copy data.

Yes, I intend to use the libraries (rsp. the subset exposed by the SharpSNV 
wrapper) for everything. That's why I'm looking for an API call to gather that 
information.
 
> Why do you want to know if a working copy changed its storage type?

When the user opens a CoDeSys project which was created or modified by a newer 
(future) CoDeSys version, that project may have an embedded working copy which 
was created (or upgraded to) a newer format. When detecting this, I want to 
inform the user that the working copy has a future, incompatible format. That 
means he either has to use a newer version of our software (which knows how to 
handle that working copy as it includes the newer client version), or he has to 
disconnect the project from subversion (which turns it into an unversioned 
project by dropping the working copy).

One possibility is to create some versioning scheme and save it into the 
project meta data, the other possibility is to let Subversion itself detect 
whether it can handle the working copy.

(I blindly assume that Subversion 1.6.16 is not able to downgrade an existing 
workingcopy from future, incompatible formats back to 1.6 :-).

Regards,
Markus

AW: Detect incompatible (future) workingcopy format.

[Markus Schaber]

Hi, Les,

> Von: Les Mikesell [mailto:lesmikes...@gmail.com]

[> ] 
> >> What is the safest future-compatible way to check for an incompatible
> >> / unknown working copy format which was written by a future
> >> subversion version? (e. G. WC-NG by SVN 1.7?)
> >>
> >> My idea was to run status with depth=empty on the workingcopy root,
> >> and check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code.
> >>
> >> Is there a function specifically designed for this purpose?
> >
> > No. The current library functions are forward compatible for the
> > entire 1.x range. The working copy storage is considered to be an
> > internal artifact, meaning you're supposed to use the libraries (e.g.
> > through the python bindings) to access the working copy data.
> 
> Doesn't that assume that there is only one version of the library that can
> access a working copy location or at least that the versions only go
> forward over time?  There are a large number of ways that assumption can
> be wrong.

As far as I see, no.

If I were about to make that assumption, I'd encode the client library version 
into our project metadata, and trigger the error handling when that version 
mismatches.

But I want to ask the subversion library whether it can handle the working copy 
version, and inform the user if subversion cannot handle it.

Note that we deliver SharpSvn based on Subversion 1.6.16, and this is our first 
release including subversion, so the implicit upgrade done by earlier svn 
versions is no use case for us, as no working copies in the old format exist.

Upgrades to future versions (either implicit or explicit as for wc-ng) will be 
handled by code we write when we ship an update bundled with a newer Version of 
Subversion requiring that upgrade.

So the only problematic case left is when the user opens a project with a 
working copy in a new, unknown format. This is the case I want to detect 
reliably, so that I can inform the user about the solutions (either use a newer 
version of our software, or disconnect the project from subversion).

Best regards,
Markus Schaber

Re: Help with constant conflicts

[K.L.]

On Fri, May 13, 2011 at 4:35 PM, Stephen Butler  wrote:
>
> On May 13, 2011, at 13:41 , K.L. wrote:
>
>> Hi,
>>
>> Having problems with merge.
>
> [...]
>
>> me@localhost /srv/www/svnbugs/branches/branch1 $ svn merge
>> svn+ssh://example.com/var/svn/svnbugs/trunk
>> --- Merging r4 through r5 into '.':
>> A    dir2
>
> [...]
>
>> me@localhost /srv/www/svnbugs/trunk $ svn merge
>> svn+ssh://example.com/var/svn/svnbugs/branches/branch1
>> --- Merging r4 through r7 into '.':
>>   C dir2
>> A    dir3
>> Summary of conflicts:
>>  Tree conflicts: 1
>> me@localhost /srv/www/svnbugs/trunk $ svn st
>> M      .
>>      C dir2
>>>  local add, incoming add upon merge
>> A  +    dir3
>
> [...]
>
>> Is it a bug or we issue wrong commands?
>>
>
> The second merge was wrong.  To merge branch1 changes back to
> the trunk, use 'merge --reintegrate ^/branches/branch1'.
>
> See the section "Reintegrating a branch" in the SVN Book:
>
>  http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
Thanks. We used reintegrate option occasionally without knowing its
true purpose and assuming it's default when merging into trunk.
I've also read that svn 1.6 allows for multiple reintegrates. Can you
confirm it? Do multiple reintegrates completely equivalent to delete
and copy if so? And is it safe to recreate branch with the same name
as deleted?

Regards.
Kostia

Re: Detect incompatible (future) workingcopy format.

[Konstantin Kolinko]

2011/5/13 Markus Schaber :
> Hi,
>
> What is the safest future-compatible way to check for an incompatible /
> unknown working copy format which was written by a future subversion
> version? (e. G. WC-NG by SVN 1.7?)
>

In the change log for Subversion 1.6 [1] there is the following line for 1.6.9.

* teach 1.6.x to recognize 1.7 working copies (1.6.x-future-proof branch)

I do not have a ready answer for your question, but the above may give
you some clue where to look at.

[1] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

IIRC, the purpose of those changes was to print a warning for 1.6
users if they invoke svn on an 1.7 working copy.

Best regards,
Konstantin Kolinko

Possible bug in pre-revprop-change and post-revprop-change hooks

[Aliasgar Ganiji]

I was in the process of implementing pre-revprop-change and post-revprop-change 
hooks in my company to handle changes to the svnn:log property.  As per the 
SubVersion Redbook;

1.   pre-revprop-change should be able to access the intended new value of 
the property via standard input.  However, what is receives is the previous 
property value.

2.   Similarly, post-revprop-change should be able to access the previous 
value of the property via standard input.  However, what is receives is the new 
property value.

Has anyone else observed this?  Can I get a confirmation that this is indeed a 
bug.

subversion 1.4.2

[Eric Manceau]

Hello,

I am struggling with an old version of subversion : 1.4.2
Is it safe for the repository to adopt the 1.6.16 version?

Moreover I want to split an old repos in 2 new repos without losing 
revision of my files :


Old Repo
   |--data
   |-- test

New Repo 1
   | --data

New Repo 2
   | --data

Svndumpfilter with 1.4 did not help and the svn command as well so did 
the tools evolve in the 1.6 version in order to achieve this goal?


Thank you for your answer.

Best regards,
E. MANCEAU
<>

RE: Help with constant conflicts

[Bob Archer]

> On Fri, May 13, 2011 at 4:35 PM, Stephen Butler 
> wrote:
> >
> > On May 13, 2011, at 13:41 , K.L. wrote:
> >
> >> Hi,
> >>
> >> Having problems with merge.
> >
> > [...]
> >
> >> me@localhost /srv/www/svnbugs/branches/branch1 $ svn merge
> >> svn+ssh://example.com/var/svn/svnbugs/trunk
> >> --- Merging r4 through r5 into '.':
> >> A    dir2
> >
> > [...]
> >
> >> me@localhost /srv/www/svnbugs/trunk $ svn merge
> >> svn+ssh://example.com/var/svn/svnbugs/branches/branch1
> >> --- Merging r4 through r7 into '.':
> >>   C dir2
> >> A    dir3
> >> Summary of conflicts:
> >>  Tree conflicts: 1
> >> me@localhost /srv/www/svnbugs/trunk $ svn st
> >> M      .
> >>      C dir2
> >>>  local add, incoming add upon merge
> >> A  +    dir3
> >
> > [...]
> >
> >> Is it a bug or we issue wrong commands?
> >>
> >
> > The second merge was wrong.  To merge branch1 changes back to
> > the trunk, use 'merge --reintegrate ^/branches/branch1'.
> >
> > See the section "Reintegrating a branch" in the SVN Book:
> >
> >  http://svnbook.red-
> bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.brancheme
> rge.basicmerging.reintegrate
> Thanks. We used reintegrate option occasionally without knowing its
> true purpose and assuming it's default when merging into trunk.

No it isn't default. svn doesn't know if you are merging into trunk... and 
trunk is just a convention. 

I suggest you read the merging/branching chapter in the svn book. It really 
helps to understand how things work if you want to use it effectively.

> I've also read that svn 1.6 allows for multiple reintegrates. Can
> you
> confirm it? Do multiple reintegrates completely equivalent to
> delete
> and copy if so? 

No... read the book on continuing to use a branch after re-integration. It is 
possible but you have to be pro-active to allow it by doing a --record-only 
merge from trunk of the revision which is the commit of the merge from the 
branch.

> And is it safe to recreate branch with the same name as deleted?

Sure... not a problem.

Just keep in mind you know the semantics of your branch. 

If it is a feature branch you are going to generally merge from trunk as you 
work on the feature and then reintegrate the branch when you are done with the 
feature. Since you are done with the feature you [normally would] delete the 
branch.

BOb

RE: subversion 1.4.2

[Bob Archer]

> I am struggling with an old version of subversion : 1.4.2 Is it
> safe for the repository to adopt the 1.6.16 version?

Yes... make sure you svn upgrade the repo or do a dump/load cycle to bring it 
up to the newest repository format.


> Moreover I want to split an old repos in 2 new repos without losing
> revision of my files :
> 
> Old Repo
> |--data
> |-- test
> 
> New Repo 1
> | --data
> 
> New Repo 2
> | --data
> 
> Svndumpfilter with 1.4 did not help and the svn command as well so
> did the tools evolve in the 1.6 version in order to achieve this
> goal?

Not sure what you meant by "did not help". That is the primary method for 
moving a subset of paths from one repository to another. Do you really NEED to 
break it into two repositories? What is the reason you want to do this, it 
might not be necessary.

BOb

Re: subversion 1.4.2

[Eric Manceau]

Thanks for quick answer.

Bob Archer a écrit :

I am struggling with an old version of subversion : 1.4.2 Is it
safe for the repository to adopt the 1.6.16 version?



Yes... make sure you svn upgrade the repo or do a dump/load cycle to bring it 
up to the newest repository format.
  

Okay I will have a try.


  

Moreover I want to split an old repos in 2 new repos without losing
revision of my files :

Old Repo
|--data
|-- test

New Repo 1
| --data

New Repo 2
| --data

Svndumpfilter with 1.4 did not help and the svn command as well so
did the tools evolve in the 1.6 version in order to achieve this
goal?



Not sure what you meant by "did not help". That is the primary method for 
moving a subset of paths from one repository to another. Do you really NEED to break it 
into two repositories? What is the reason you want to do this, it might not be necessary.

BOb
  
I did use svndumpfilter to isolate test and load into New Repo 2 but 
after checking we notice that the new repos did not hold the last 
revision of a file but instead an old one.


Sorry about my schema which is false.
Here is the corrected version :

New Repo 2
   | --test

As you can see we want to gather all tests of several differents repos 
into a unique repo but we want to keep revision of the original repos 
and it seems to be hard to achieve.

Maybe impossible?

Eric



--
+++
Si vous recevez ce courriel par erreur, toutes mes coordonees sont dans "informations complémentaires" sur ma carte en piece jointe. 
If you received this message in error, read "informations complementaires" in my card attached with this mail to contact me.


<>

Re: Possible bug in pre-revprop-change and post-revprop-change hooks

[Johan Corveleyn]

On Fri, May 13, 2011 at 4:40 PM, Aliasgar Ganiji  wrote:
> I was in the process of implementing pre-revprop-change and
> post-revprop-change hooks in my company to handle changes to the svnn:log
> property.  As per the SubVersion Redbook;
>
> 1.   pre-revprop-change should be able to access the intended new value
> of the property via standard input.  However, what is receives is the
> previous property value.
>
> 2.   Similarly, post-revprop-change should be able to access the
> previous value of the property via standard input.  However, what is
> receives is the new property value.
>
>
>
> Has anyone else observed this?  Can I get a confirmation that this is indeed
> a bug.

That's not what happens on my setup (svn 1.5.4 on Solaris).

I can confirm that my pre-revprop-change hook receives the new value
on stdin, and post-revprop-change hook receives the old value on
stdin.

-- 
Johan

RE: Possible bug in pre-revprop-change and post-revprop-change hooks

[Aliasgar Ganiji]

This is our setup svn 1.6.6 on Linux x86_64.  What if the hooks are broken in 
this version?  Can someone with this version of svn verify?
---
Ali



-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: Friday, May 13, 2011 12:29 PM
To: Aliasgar Ganiji
Cc: users@subversion.apache.org
Subject: Re: Possible bug in pre-revprop-change and post-revprop-change hooks

On Fri, May 13, 2011 at 4:40 PM, Aliasgar Ganiji  wrote:
> I was in the process of implementing pre-revprop-change and
> post-revprop-change hooks in my company to handle changes to the svnn:log
> property.  As per the SubVersion Redbook;
>
> 1.   pre-revprop-change should be able to access the intended new value
> of the property via standard input.  However, what is receives is the
> previous property value.
>
> 2.   Similarly, post-revprop-change should be able to access the
> previous value of the property via standard input.  However, what is
> receives is the new property value.
>
>
>
> Has anyone else observed this?  Can I get a confirmation that this is indeed
> a bug.

That's not what happens on my setup (svn 1.5.4 on Solaris).

I can confirm that my pre-revprop-change hook receives the new value
on stdin, and post-revprop-change hook receives the old value on
stdin.

-- 
Johan

Re: Possible bug in pre-revprop-change and post-revprop-change hooks

[Ryan Schmidt]

On May 13, 2011, at 13:38, Aliasgar Ganiji wrote:

> This is our setup svn 1.6.6 on Linux x86_64.  What if the hooks are broken in 
> this version?  Can someone with this version of svn verify?

The hooks seem to be working correctly for me on Mac OS X 10.6.7 x86_64 with 
Subversion 1.6.16 installed by MacPorts. I see nothing in the 1.6.x series 
entries in the CHANGES file relating to fixing such a bug, so I would guess 
such a bug does not exist in the 1.6.x series. Attached are the hook scripts I 
used to verify it functions correctly. I installed those hook scripts in a new 
test repository, committed a revision, then changed its log message a few 
times, then read the log file the hook script created.





pre-revprop-change
Description: Binary data


post-revprop-change
Description: Binary data

Re: Detect incompatible (future) workingcopy format.

[Daniel Shahaf]

Markus Schaber wrote on Fri, May 13, 2011 at 11:20:11 +0200:
> Hi,
> 
> What is the safest future-compatible way to check for an incompatible /
> unknown working copy format which was written by a future subversion
> version? (e. G. WC-NG by SVN 1.7?)
> 
> My idea was to run status with depth=empty on the workingcopy root, and
> check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code.
> 

What about SVN_ERR_WC_UPGRADE_REQUIRED?

> Is there a function specifically designed for this purpose?
> 

If there isn't, it seems like a good idea to have one, in order for the
library to clearly communicate "I cannot perform  on this working copy unless you upgrade it".

> Regards,
> Markus
>