Re: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

[Johan Corveleyn]

On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@gmail.com]
>> Sent: woensdag 19 oktober 2011 0:32
>> To: Bert Huijben
>> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
>> Subject: Re: Re[4]: Very big problems with access rights (authz file
> using) in
>> SVN v1.7.0
>>
>> On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben  wrote:
>> >> -Original Message-
>> >> From: Bert Huijben [mailto:b...@qqmail.nl]
>> >> Sent: dinsdag 18 oktober 2011 19:43
>> >> To: 'Andrey'; 'Johan Corveleyn'
>> >> Cc: 'Stefan Sperling'; users@subversion.apache.org
>> >> Subject: RE: Re[4]: Very big problems with access rights (authz file
>> > using) in
>> >> SVN v1.7.0
>> >
>> >> Ok, with that information I reproduced this problem in the Subversion
>> test
>> >> suite on upgrading a working copy with server excluded (or 'absent')
>> > nodes.
>> >> After the upgrade updates fail.
>> >>
>> >> I will look into fixing this problem tomorrow. (If somebody else wants
> to
>> >> look first, please let me know ;-)
>> >
>> > The problem is fixed on trunk and I nominated it for backport.
>> >
>> > Please ping your favorite committer to make him review the patch for
>> > inclusion in 1.7.1 ;)
>> >
>> > All upgrades of working copies that contains information on
> subdirectories
>> > where the user doesn't have access to, have this same problem. I think
> the
>> > only real way to resolve this issue on a working copy is checking out
> again.
>>
>> Would 'svn up -r0 path/to/restrictedDir' on an
>> already-upgraded-but-broken-wc also be able to repair it?
>
> No, this won't work.
>
> This trick relies on receiving the update from the current state to r0 from
> the server, but you don't have the authorization to get this update from the
> server.

And 'svn up -r0 path/to/parentOfRestrictedDir'?

-- 
Johan

Re: mergeinfo marked not inheritable on sparse checkout

[Johan Corveleyn]

On Wed, Oct 19, 2011 at 1:44 AM, Douglas Wilson
 wrote:
> If I have a sparse checkout of /trunk (say it has subdirectories dir1
> and dir2, so I just have a working copy of /trunk/dir1), commit some
> changes, switch my checkout to a branch, then try to merge the changes
> I just committed, the mergeinfo property gets revisions marked with
> "*" in the branch root, and updates mergeinfo in the directory with
> the changes.
>
> Is there any reason the merge has to have the "*", since there were no
> changes outside of my working copy?

Is this still the case with 1.7? Could you test that?

There were a lot of merge-tracking improvements and bugfixes in 1.7,
but I'm not sure if this particular issue has been addressed. See
http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracking-enhancements.

-- 
Johan

SVN to Base Clearcase

[sureshkumar nandakumar]

Hi,

I need your help to sync my svn branch source with Base clearcase
branch.

*SVN Details:*
We have installed latest svn version in red hat Linux & it is
accessing via Tortoise client.

*Base Clearcase Details:*
We have one more Version control tool. That is base clearcase which
was installed in AIX server.

We have two different teams. One team is working with SVN and another
team is working with IBM BASE Clearcase.
If any changes will happen in SVN branch, the same source needs to
sync with Base Clearcase.

Currently we are taking SVN branch source manually using svn export
command and moving in to Clearcase branch.
This is not right way for maintaining full Version history.

If we follow the same way, we can able to find only svn branch latest
files in Clearcase branch.
It would be great help if you suggest to me for merging svn branch
source with clearcase branch with full versions.


For example: if a.java file is having 10versions in svn branch, i need
all 10 versions to be sync with Clearcase branch. please assist me,
how i can do this from svn to Clearcase.

We are struggling more than one year.
i have tried Clearsvn tool. but it is not compatible for AIX & Linux
servers

Apart from that Is that any way to sync SVN branch to Clearcase branch
with full version history.

Re: Merge strategies?

[Johan Corveleyn]

On Wed, Oct 19, 2011 at 8:38 AM, Andrey Paramonov  wrote:
> On 18.10.2011 20:05, Daniel Shahaf wrote:
>>
>> Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:
>>>
>>> What confuses people most now is the scattered
>>> svn:mergeinfo ("Oh, why that dir has modified status, my merge
>>> shouldn't have changed it!").
>>
>> Isn't this particular issue fixed in 1.7?
>
> No, it's apparently not. What was fixed is svn:mergeinfo physical storage
> format and location in working copy. On the contrary, the
> inheritance/elision rules were not (cannot be?) changed. Basically,
> everything said in
> http://www.collab.net/community/subversion/articles/merge-info.html about
> "pesky implementation details" remains valid.
>
> Consider the following example. Users typically merge to /release/1.0.1/.
> Merge info is recorded to svn:mergeinfo of /release/1.0.1/. Now consider
> someone merges once to /release/1.0.1/some/subdir/. Possible reasons:
> 1) Her changes belong only to some/subdir/.
> 2) She has checkout of just /release/1.0.1/some/subdir/, not the whole
> /release/1.0.1/.
> 3) She doesn't have access to /release/1.0.1/ at all, only to
> /release/1.0.1/some/subdir/.
>
> Ok, now another user merges to /release/1.0.1/. Suppose his changes only
> belong to another/dir. But he would see that /release/1.0.1/some/subdir/ has
> modified flag! This is very confusing and hard to explain (I have tried).

This precisely the behavior that should have been improved in 1.7 [1].
So I'm surprised that it is not. You are testing this (the part with
"now another user merges ...") with a 1.7 client, yes?


[1] 
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording

-- 
Johan

Re: Problem with diff

[Adam Miazga]

Hi

Daniel try this way

1. download file from first message
2. commit this file without modification
3. add new line via
echo "test" >>kadr.polon.p
4. commit changed file
5.generate diff

I tried to repeat this situation with another file. All my attempts have failed.
This file have corrupted line endings and open and save this file in
editor which modfied line endings repaired it.

Successful attempts
Adam Miazga

2011/10/18 Andreas Krey :
> On Tue, 18 Oct 2011 17:54:41 +, Daniel Shahaf wrote:
> ...
>> svnmucc, and then append two lines and diff before/after committing,
>> but still couldn't reproduce your issue.
>
> I can't reproduce it on the linux box, either. At least not exactly.
> This is going to be fun.
>
> My apple produces (without any svn:prop):
>
> ===
> --- kadr.polon.p        (revision 1)
> +++ kadr.polon.p        (revision 2)
> @@ -461,6 +461,8 @@
>    447    EMPTY TEMP-TABLE tt_tytnauk.
>    448    EMPTY TEMP-TABLE tt_stnauk.
>    449    pOstatni = vIlosc.
> +   450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> +   451 END.
>    450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
>    451 END.
>    452 {ws_i/log.i}
>
> and the linux box makes that
>
> ===
> --- kadr.polon.p        (revision 1)
> +++ kadr.polon.p        (revision 2)
> @@ -463,4 +463,6 @@
>    449    pOstatni = vIlosc.
>    450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
>    451 END.
> +   452 {ws_i/log.i}
> +
>    452 {ws_i/log.i}
>
> Uninitialized variable that then points to the wrong lines?
>
> Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds 
> Date: Fri, 22 Jan 2010 07:29:21 -0800
>

Re: Merge strategies?

[Andrey Paramonov]

On 19.10.2011 11:44, Johan Corveleyn wrote:

On Wed, Oct 19, 2011 at 8:38 AM, Andrey Paramonov  wrote:

On 18.10.2011 20:05, Daniel Shahaf wrote:


Andrey Paramonov wrote on Tue, Oct 18, 2011 at 11:40:37 +0400:


What confuses people most now is the scattered
svn:mergeinfo ("Oh, why that dir has modified status, my merge
shouldn't have changed it!").


Isn't this particular issue fixed in 1.7?


No, it's apparently not. What was fixed is svn:mergeinfo physical storage
format and location in working copy. On the contrary, the
inheritance/elision rules were not (cannot be?) changed. Basically,
everything said in
http://www.collab.net/community/subversion/articles/merge-info.html about
"pesky implementation details" remains valid.

Consider the following example. Users typically merge to /release/1.0.1/.
Merge info is recorded to svn:mergeinfo of /release/1.0.1/. Now consider
someone merges once to /release/1.0.1/some/subdir/. Possible reasons:
1) Her changes belong only to some/subdir/.
2) She has checkout of just /release/1.0.1/some/subdir/, not the whole
/release/1.0.1/.
3) She doesn't have access to /release/1.0.1/ at all, only to
/release/1.0.1/some/subdir/.

Ok, now another user merges to /release/1.0.1/. Suppose his changes only
belong to another/dir. But he would see that /release/1.0.1/some/subdir/ has
modified flag! This is very confusing and hard to explain (I have tried).


This precisely the behavior that should have been improved in 1.7 [1].
So I'm surprised that it is not. You are testing this (the part with
"now another user merges ...") with a 1.7 client, yes?

[1] 
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording



Ah, I now tested a bit more thoroughly and I see that it's fixed indeed. 
Very good, and sorry for the noise.


What about my other fears, bloated svn:mergeinfo and svn:mergeinfo 
conflicts?


Best wishes,
Andrey Paramonov

SVN to Base Clearcase

[sureshkumar nandakumar]

Hi

Please can anyone, advice to me..




I need your help to sync my svn branch source with Base clearcase branch.



SVN Deatils:

We have installed latest svn version in red hat Linux & it is accessing via
Tortoise client.



Base Clearcase Details:

We have one more Version control tool. That is base clearcase which was
installed in AIX server.



We have two different teams. One team is working with SVN and another team
is working with IBM BASE Clearcase.

If any changes will happen in SVN branch, the same source needs to sync with
Base Clearcase.



Currently we are taking SVN branch source manually using svn export command
and moving in to Clearcase branch.

This is not right way for maintaining full Version history.



If we follow the same way, we can able to find only svn branch latest files
in Clearcase branch.

It would be great help if you suggest to me for merging svn branch source
with clearcase branch with full versions.





For example: if a.java file is having 10versions in svn branch, i need all
10 versions to be sync with Clearcase branch. please assist me, how i can do
this from svn to Clearcase.



We are struggling more than one year.

i have tried Clearsvn tool. but it is not compatible for AIX & Linux servers



Apart from that Is that any way to sync SVN branch to Clearcase branch with
full version history.

RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0

[Bert Huijben]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: woensdag 19 oktober 2011 9:26
> To: Bert Huijben
> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
> Subject: Re: Re[4]: Very big problems with access rights (authz file
using) in
> SVN v1.7.0
> 
> On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben  wrote:
> >
> >
> >> -Original Message-
> >> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> >> Sent: woensdag 19 oktober 2011 0:32
> >> To: Bert Huijben
> >> Cc: Andrey; Stefan Sperling; users@subversion.apache.org
> >> Subject: Re: Re[4]: Very big problems with access rights (authz file
> > using) in
> >> SVN v1.7.0
> >>
> >> On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben  wrote:
> >> >> -Original Message-
> >> >> From: Bert Huijben [mailto:b...@qqmail.nl]
> >> >> Sent: dinsdag 18 oktober 2011 19:43
> >> >> To: 'Andrey'; 'Johan Corveleyn'
> >> >> Cc: 'Stefan Sperling'; users@subversion.apache.org
> >> >> Subject: RE: Re[4]: Very big problems with access rights (authz file
> >> > using) in
> >> >> SVN v1.7.0
> >> >
> >> >> Ok, with that information I reproduced this problem in the
Subversion
> >> test
> >> >> suite on upgrading a working copy with server excluded (or 'absent')
> >> > nodes.
> >> >> After the upgrade updates fail.
> >> >>
> >> >> I will look into fixing this problem tomorrow. (If somebody else
wants
> > to
> >> >> look first, please let me know ;-)
> >> >
> >> > The problem is fixed on trunk and I nominated it for backport.
> >> >
> >> > Please ping your favorite committer to make him review the patch for
> >> > inclusion in 1.7.1 ;)
> >> >
> >> > All upgrades of working copies that contains information on
> > subdirectories
> >> > where the user doesn't have access to, have this same problem. I
think
> > the
> >> > only real way to resolve this issue on a working copy is checking out
> > again.
> >>
> >> Would 'svn up -r0 path/to/restrictedDir' on an
> >> already-upgraded-but-broken-wc also be able to repair it?
> >
> > No, this won't work.
> >
> > This trick relies on receiving the update from the current state to r0
from
> > the server, but you don't have the authorization to get this update from
> the
> > server.
> 
> And 'svn up -r0 path/to/parentOfRestrictedDir'?

This has the same effect as a normal update op parentOfRestricted dir. So
you probably receive a tree conflict (restricted dir is not unmodified)
*and* the failed update (security problem).

Bert

Subversion Exception!

[Peter Lucas]

I deleted a file intending to follow up with an update.
Tortoise is now dead - re-boot required.


---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
 line 672: assertion failed (checksum != NULL)
---
OK
---

Re: Subversion error

[Daniel Shahaf]

What's happening here is that svn_client_checkout3() asserts that its
API contract is being fulfilled.  So, either TortoiseSVN fails to
svn_uri_canonicalize() the URL before passing it to libsvn_client, or
svn_uri_canonicalize() called by tsvn and svn_uri_is_canonical() called
by the assertion disagree.

As Konstantin said, seeing the URL would be useful.

Konstantin Kolinko wrote on Wed, Oct 19, 2011 at 09:48:18 +0400:
> 2011/10/19 Isaac Hogue :
> > I'm running Windows 7 64 bit and trying to checkout an existing svn
> > repository.  I am able to connect to the same from an alternate computer.
> > Thanks,
> > -Isaac
> > ---
> > Subversion Exception!
> > ---
> > Subversion encountered a serious problem.
> > Please take the time to report this on the Subversion mailing list
> > (users@subversion.apache.org)
> > with as much information as possible about what
> > you were trying to do.
> > But please first search the mailing list archives for the error message
> > to avoid reporting the same problem repeatedly.
> > You can find the mailing list archives at
> > http://subversion.apache.org/mailing-lists.html
> > Subversion reported the following
> > (you can copy the content of this dialog
> > to the clipboard using Ctrl-C):
> > In file
> >  'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_client\checkout.c'
> >  line 94: assertion failed (svn_uri_is_canonical(url, pool))
> 
> 
> The message says about wrong URL.
> What was the URL that you tried to check out? You may replace parts of
> it, but general idea must be clear.
> 
> You can reopen checkout dialog - there is a drop-down list with
> previous URLs there,
> or look in the activity log (TortoiseSVN -> Settings -> go to "Saved
> Data" page -> see "Action log" -> click "Show").
> 
> 
> Best regards,
> Konstantin Kolinko

Re: Subversion 1.7 and 'relocate'

[Ulrich Eckhardt]

Am 18.10.2011 10:02, schrieb Daniel Shahaf:

Johan Corveleyn wrote on Tue, Oct 18, 2011 at 09:48:46 +0200:
! is special in unix shells.  But ^./ for the wc root?


The caret ("^") is special in other shells, namely cmd.exe. Also, wasn't 
the caret already used to refer to the repository root?


Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: 1.7.0 does not build on Solaris9

[Daniel Shahaf]

Andreas Krey wrote on Wed, Oct 19, 2011 at 08:19:29 +0200:
> On Tue, 18 Oct 2011 23:21:12 +, Daniel Shahaf wrote:
> > Andreas Krey wrote on Tue, Oct 18, 2011 at 23:15:29 +0200:
> > > On Tue, 18 Oct 2011 22:12:47 +, Daniel Shahaf wrote:
> > > ...
> > > > - those foo.h file generated from foo.sql files are supposed to be
> > > >   pre-generated in the tarball
> > > 
> > > They are. Except that I copied over the tree, and the timestamps
> > > afterwards were so that it tought it necessary to recreate. Ouch.
> > > 
> > 
> > Is there something we can do in the release process to help avoid this?
> 
> You would need to remove the build rules for the .h files in the
> makefile when you ship the tar file. A bit complicated. (And who
> does not work directly from an unpacked tarfile and instead copy
> it around?. I did because the target machine has no direct inet
> access and now wget or simile.) A note in the INSTALL would be
> simpler, I guess.
> 
> Anyway, the build still has some other issues (sqlite ftruncate, -lintl),
> but they can be overcome.
> 

Actually it's not as hard as it sounds.  For creating tarballs we run
autogen.sh with a specific argument; and the relevant makefile rules are
generated by build.conf rules.  So, it's conceiveable we could
autogen.sh invoke [the tool that uses] build.conf in a way that say,
"Drop those Makefile rules".

I haven't paused to think if it's a good idea, by the way, I'm just
flowing along with your suggestion.

> ...
> > > + svnadmin create repo 
> > > svnadmin: Version mismatch in 'svn_delta': found 1.5.5, expected 1.7.0
> ...
> > Did you build with debug or maintainer flags?
> 
> No; actually I was stupid...
> 
> > ldd svnadmin
> 
> which shows me that it links to the old .so files, which in turn
> indicates that I made a minor mistake in setting LD_LIBRARY_PATH.
> (Unfortunately that seems to take precedence over what -r told
> the linker.)
> 
> Now it fails differently:
> 
> + svn commit -m 1 
> Adding kadr.polon.p
> Transmitting file data .ld.so.1: svn: fatal: relocation error: file 
> /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound: 
> referenced symbol not found
> 

That's a symbol from zlib, used by the svndiff1 code.  If you don't want
to do the ldd dance again then 'svnadmin create --pre-1.4-compatible'
might workaround the error.

> > (or 'libtool --mode=execute ldd ./subversion/svnadmin/svnadmin', if
> > svnadmin is a libtool wrapper.)
> 
> What is this libtool good for, anyway? Looks like it isn't really
> doing anything.

In this case it allows running the in-tree executables against the
in-tree libraries.  Yes, it receives some criticism from time to time.

Re: 1.7.0 does not build on Solaris9

[Philip Martin]

Andreas Krey  writes:

> + svn commit -m 1 
> Adding kadr.polon.p
> Transmitting file data .ld.so.1: svn: fatal: relocation error: file 
> /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound: 
> referenced symbol not found

I think that is a zlib symbol.  Subversion links some libraries against
zlib but doesn't link executables to zlib directly, relying on the
library to pull them in. If you build using

 make EXTRA_LDFLAGS=-lz

that will probably fix the problem.  If zlib is in some non-standard
location you may need

 make EXTRA_LDFLAGS='-lz -L/some/dir'


-- 
Philip

Re: Problem with diff

[Daniel Shahaf]

Adam Miazga wrote on Wed, Oct 19, 2011 at 10:17:56 +0200:
> Hi
> 
> Daniel try this way
> 
> 1. download file from first message
> 2. commit this file without modification
> 3. add new line via
> echo "test" >>kadr.polon.p
> 4. commit changed file
> 5.generate diff
> 

Thanks for the recipe, however, I already tried those steps, including
generating a diff both before and after the commit. (and couldn't
reproduce)

Adam, Andreas: when you say what passes/fails for you, please also
mentino the environment.  I've so far tested on 32bit Linux and I plan
to test in a couple more environments once I rebuild trunk on them.

> I tried to repeat this situation with another file. All my attempts have 
> failed.
> This file have corrupted line endings and open and save this file in
> editor which modfied line endings repaired it.
> 
> Successful attempts
> Adam Miazga
> 
> 2011/10/18 Andreas Krey :
> > On Tue, 18 Oct 2011 17:54:41 +, Daniel Shahaf wrote:
> > ...
> >> svnmucc, and then append two lines and diff before/after committing,
> >> but still couldn't reproduce your issue.
> >
> > I can't reproduce it on the linux box, either. At least not exactly.
> > This is going to be fun.
> >
> > My apple produces (without any svn:prop):
> >
> > ===
> > --- kadr.polon.p        (revision 1)
> > +++ kadr.polon.p        (revision 2)
> > @@ -461,6 +461,8 @@
> >    447    EMPTY TEMP-TABLE tt_tytnauk.
> >    448    EMPTY TEMP-TABLE tt_stnauk.
> >    449    pOstatni = vIlosc.
> > +   450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> > +   451 END.
> >    450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> >    451 END.
> >    452 {ws_i/log.i}
> >
> > and the linux box makes that
> >
> > ===
> > --- kadr.polon.p        (revision 1)
> > +++ kadr.polon.p        (revision 2)
> > @@ -463,4 +463,6 @@
> >    449    pOstatni = vIlosc.
> >    450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> >    451 END.
> > +   452 {ws_i/log.i}
> > +
> >    452 {ws_i/log.i}
> >
> > Uninitialized variable that then points to the wrong lines?
> >
> > Andreas
> >
> > --
> > "Totally trivial. Famous last words."
> > From: Linus Torvalds 
> > Date: Fri, 22 Jan 2010 07:29:21 -0800
> >

Re: Upgrade to svn 1.7 on cygwin causes W155007 not a working copy?

[Daniel Shahaf]

Mark Utting wrote on Wed, Oct 19, 2011 at 11:40:08 +1000:
> Summary:
> It seems that the new top-level .svn directory spontaneously disappears
> sometimes?
> Which leaves me with a useless working copy...
> 

Do you have some cron job or other background process that walks around
and randomly deletes files or directories?

> Since svn 1.7 was incompatible with my existing working copy, I did 'svn
> upgrade' in my top-level directory, which contains several projects from
> different SVN repositories.  It removed all the .svn directories in most of
> those subdirectories (all the ones that belonged to my main SVN repository),
> but then failed to create a top-level .svn directory!

Actually, it doesn't "create" a top-level .svn dir; it re-uses the .svn
dir in the root of the 1.6 wc for itself.

Re: Problem with diff

[Andreas Krey]

On Wed, 19 Oct 2011 11:37:25 +, Daniel Shahaf wrote:
...
> Adam, Andreas: when you say what passes/fails for you, please also
> mentino the environment.  I've so far tested on 32bit Linux and I plan
> to test in a couple more environments once I rebuild trunk on them.

Do you build your test subject from the tar file or directly from svn?

The funny thing is that the resulting diffs do not only differ from
the expected result but are also different between machines.

That's why I wanted to build for Solaris: To see what happens there.

...
> > > My apple produces (without any svn:prop):

Plain 10.5.8 with compiler from xcode, compiled from source. Probably 32bit.

> > > +   450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> > > +   451 END.

> > > and the linux box makes that

SuSE 10.2, Kernel (irrelevant) 2.6.18.8-0.3, apparently 64bit executable.

> > > +   452 {ws_i/log.i}
> > > +

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Merge strategies?

[Stefan Sperling]

On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
> What about my other fears, bloated svn:mergeinfo

The entire svn:mergeinfo property is stored in RAM and parsed from
string form into a data structure (nested hash table) before it is used.
With modern hardware, you'd have to hit svn:mergeinfo sizes that go
into hundreds of megabytes before you'll notice any slowdown.

> and svn:mergeinfo conflicts?

Have you ever seen a mergeinfo conflict? I haven't.

Re: Subversion 1.7 and 'relocate'

[Daniel Shahaf]

Ulrich Eckhardt wrote on Wed, Oct 19, 2011 at 11:34:03 +0200:
> Am 18.10.2011 10:02, schrieb Daniel Shahaf:
> >Johan Corveleyn wrote on Tue, Oct 18, 2011 at 09:48:46 +0200:
> >! is special in unix shells.  But ^./ for the wc root?
> 
> The caret ("^") is special in other shells, namely cmd.exe. Also,
> wasn't the caret already used to refer to the repository root?

^/ refers to the repository root.  ^./ is not special and re-uses the
character that has learnt to escape and gotten used to escaping.

http://subversion.tigris.org/issues/show_bug.cgi?id=3883

Re: 1.7.0 does not build on Solaris9

[Andreas Krey]

On Wed, 19 Oct 2011 10:36:28 +, Philip Martin wrote:
> Andreas Krey  writes:
...
> I think that is a zlib symbol.  Subversion links some libraries against
> zlib but doesn't link executables to zlib directly, relying on the
> library to pull them in. If you build using
> 
>  make EXTRA_LDFLAGS=-lz

ldd already tells me the line 'libz.so =>   /usr/lib/libz.so'
which is a bit irritating because why did get-deps pull zlib in the
first place when it uses the system one?

/usr/lib/libz.so does not seem to have any symbol containing 'Bound',
thus probably being before 1.2.0.

>  make EXTRA_LDFLAGS='-lz -L/some/dir'

That will be useful for -lintl.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

RE: subversion-1/svn_wc.h:1210: error: comma at end of enumerator list

[Tony Sweeney]

 

-Original Message-
From: Peter Johansson [mailto:peterandrejohans...@gmail.com] 
Sent: 18 October 2011 22:35
To: users@subversion.apache.org
Cc: svndigest-us...@lists.sourceforge.net
Subject: subversion-1/svn_wc.h:1210: error: comma at end of enumerator
list

Hello,

When I compiled with GCC (4.2.1) with compiler option -pedantic against
header file `svn_wc.h' in subversion version 1.7 I get the following
error:

In file included from main.cc:1:
/opt/local/include/subversion-1/svn_wc.h:1210: error: comma at end of
enumerator list
make: *** [main] Error 1

I suspect this is caused by a typo in svn_wc.h at line 1210:

   /** The operation skipped the path because it was conflicted.
* @since New in 1.7. */
   svn_wc_notify_skip_conflicted,

} svn_wc_notify_action_t;

because other enums in the same file have no comma after the last item. 
Is there are reason to have this comma that I'm missing or could it be
removed?

--

The trailing comma is explicitly invalid per ANSI C 89 (though some
compilers, notably GCC, permitted it).  C99 removes this restriction.
It's valid everywhere without the comma, so it's perfectly safe (and
probably desirable) to remove it.  A Google search on 'trailing comma
enum' will find many instances of people submitting similar patches to
other open source projects.

Tony.


Thanks and please let me know if you need further information from me.

--
Cheers,
Peter

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1831 / Virus Database: 2092/4560 - Release Date:
10/18/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Problem with diff

[Adam Miazga]

I've tested in Windows 7
Command line svn from VisualSVN version 2.5.0
GUI via TortoiseSVN 1.7 RC1,TortoiseSVN 1.7, TortoiseSVN 1.7
Nightbuild 22093 and TortoiseSVN 1.7 Nightbuild 22114
And SLES 10.2 x86 32bit
Subversion 1.7 builded from tar.

in all cases diff looks that same.

Adam Miazga

2011/10/19 Andreas Krey :
> On Wed, 19 Oct 2011 11:37:25 +, Daniel Shahaf wrote:
> ...
>> Adam, Andreas: when you say what passes/fails for you, please also
>> mentino the environment.  I've so far tested on 32bit Linux and I plan
>> to test in a couple more environments once I rebuild trunk on them.
>
> Do you build your test subject from the tar file or directly from svn?
>
> The funny thing is that the resulting diffs do not only differ from
> the expected result but are also different between machines.
>
> That's why I wanted to build for Solaris: To see what happens there.
>
> ...
>> > > My apple produces (without any svn:prop):
>
> Plain 10.5.8 with compiler from xcode, compiled from source. Probably 32bit.
>
>> > > +   450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
>> > > +   451 END.
>
>> > > and the linux box makes that
>
> SuSE 10.2, Kernel (irrelevant) 2.6.18.8-0.3, apparently 64bit executable.
>
>> > > +   452 {ws_i/log.i}
>> > > +
>
> Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds 
> Date: Fri, 22 Jan 2010 07:29:21 -0800
>

Re: Merge strategies?

[Andrey Paramonov]

On 19.10.2011 14:00, Stefan Sperling wrote:

On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:

What about my other fears, bloated svn:mergeinfo


The entire svn:mergeinfo property is stored in RAM and parsed from
string form into a data structure (nested hash table) before it is used.
With modern hardware, you'd have to hit svn:mergeinfo sizes that go
into hundreds of megabytes before you'll notice any slowdown.



Hm, but this parsing occurs on every invocation of "svn.exe", or I'm 
missing something?



and svn:mergeinfo conflicts?


Have you ever seen a mergeinfo conflict? I haven't.



I haven't, too, because everyone uses --ignore-ancestry here ;-)

Thanks for your comments,
Andrey Paramonov

Re: Problem with diff

[Daniel Shahaf]

Andreas Krey wrote on Wed, Oct 19, 2011 at 12:00:27 +0200:
> On Wed, 19 Oct 2011 11:37:25 +, Daniel Shahaf wrote:
> ...
> > Adam, Andreas: when you say what passes/fails for you, please also
> > mentino the environment.  I've so far tested on 32bit Linux and I plan
> > to test in a couple more environments once I rebuild trunk on them.
> 
> Do you build your test subject from the tar file or directly from svn?
> 

1.6.12 from Debian package or 1.6.x self-compiled (can't remember);
1.7.0 from upstream tarball; trunk@HEAD from svn.

> The funny thing is that the resulting diffs do not only differ from
> the expected result but are also different between machines.
> 
> That's why I wanted to build for Solaris: To see what happens there.
> 
> ...
> > > > My apple produces (without any svn:prop):
> 
> Plain 10.5.8 with compiler from xcode, compiled from source. Probably 32bit.
> 

gcc (Debian 4.4.5-8) 4.4.5

> > > > +   450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> > > > +   451 END.
> 
> > > > and the linux box makes that
> 
> SuSE 10.2, Kernel (irrelevant) 2.6.18.8-0.3, apparently 64bit executable.
> 

Debian

> > > > +   452 {ws_i/log.i}
> > > > +
> 
> Andreas
> 
> -- 
> "Totally trivial. Famous last words."
> From: Linus Torvalds 
> Date: Fri, 22 Jan 2010 07:29:21 -0800

RE: Explore repository "head" live on NFS

[Tony Sweeney]

From: Eli Bocek-Rivele [mailto:boc...@gmail.com] 
Sent: 19 October 2011 04:06
To: users@subversion.apache.org
Subject: Explore repository "head" live on NFS


Hi all, 
I'm very new to the community and I can only imagine this question has
been asked before but google searching (and looking in archives) has not
helped but it may be because I don't know how to correctly phrase the
question, but here goes. Is there a way to have an expanded view into a
repository's projects on NFS such that a user can explore it in a shell
in a read-only fashion? What I mean is if I have a repository like:

file:///repos/myproj/stuff/foo.c
I'd have on disk
/svn_explore/repos/myproj/stuff/foo.c
As a set of directories / files that I could look at that are always
'head' and are read-only and are kept up to date. I was thinking I could
orchestrate this with a cron, or maybe some changes to hooks but I was
wondering if there was an easy supported way or standard way in which
people do this. This would allow people to look into the 'latest' in the
repository without actually having to run any svn commands. 
 
You're looking for this:
http://www.jmadden.eu/index.php/svnfs/
Tony.

 

Thanks in advance for any help and I appreciate you reading such a
novice question. I'm very new to svn but already find it a powerful and
promising system.
-Eli
 

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1831 / Virus Database: 2092/4560 - Release Date:
10/18/11


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Problem with diff

[Daniel Shahaf]

Andreas Krey wrote on Tue, Oct 18, 2011 at 06:04:12 +0200:
> #!/bin/sh
  alias svn=$svn svnadmin=$svnadmin
> rm -rf svntmp
> mkdir svntmp
> cd svntmp
> svnadmin create repo
> svn checkout file://`pwd`/repo wc
> cd wc
> cp ../../kadr.polon.p .
> svn add kadr.polon.p 
> svn commit -m 1
> cat >>kadr.polon.p < 
> /**/
> EOF
> svn diff
> exit

I see the correct diff output with an 1.7.0-rc2 build, from tarball, on
a 32-bit sparc sunos box.

Re: 1.7.0 does not build on Solaris9

[Daniel Shahaf]

Andreas Krey wrote on Wed, Oct 19, 2011 at 12:08:18 +0200:
> ldd already tells me the line 'libz.so =>   /usr/lib/libz.so'
> which is a bit irritating because why did get-deps pull zlib in the
> first place when it uses the system one?

Looking at build/ac-macros/zlib.m4 I don't see any special handling for
checking if zlib exists at ./zlib (like we check for some other
dependencies).

Probably an oversight.

Re: subversion-1/svn_wc.h:1210: error: comma at end of enumerator list

[Daniel Shahaf]

Tony Sweeney wrote on Wed, Oct 19, 2011 at 11:10:35 +0100:
> The trailing comma is explicitly invalid per ANSI C 89 (though some
> compilers, notably GCC, permitted it).  C99 removes this restriction.
> It's valid everywhere without the comma, so it's perfectly safe (and
> probably desirable) to remove it.

Exactly.

If someone wants to send a patch, though, it would be nice to also fix
all other instances of a trailing comma in the C code.  (There is at
least one such instance in subversion/svn/main.c.)

Release branch merging.

[Gavin Baumanis]

Hi There everyone,

I have trunk, branches and tags. 
(the "default" repo setup)

VERY recently we swapped from continuous deployment to having a scheduled 
release strategy.
We used to simply cherry-pick or even just OS copy the required changes from 
trunk to a "special"(to us) branch any change that needed to go to production.
This special branch was ten simply copied to production.

Now, we are trying to start the "standard" release strategy,
Develop on trunk,
Merge to a release branch,
Create a tag.

I genuinely cannot recall how we created the release branch;
all I know is the symptoms of what I now face - and hope to "correct".

I did this;
cd /repos/branches/releases/1
svn merge ^/trunk --dry-run

And subsequently got a status report that everything was going to be a conflict.
So I think it's safe to say that the releases branch was created by an OS copy 
and not an SVN aware operation.

is there a pain-free way that I correct my repository to allow for successful 
trunk -> release branch merging?
I am thinking of;
 * Deleting the release branch;
 * Recreating the release branch at the revision that the release branch was 
originally created.
 * Re-merging the single trunk change that was merged to ^/branches/releases/1.0

Which should bring it to its current state - and match the 1.01 release tag.

And hopefully now allow me to merge ^/trunk -> ^/branches/releases - which 
should allow a more pain-free merge for the next release.

Do I have that right?
Is there something else I can do that would negate the requirement to recreate 
the release branch?

As always  - thanks for your assistance.


Gavin 'Beau' Baumanis.

Re: Explore repository "head" live on NFS

[Nico Kadel-Garcia]

On Tue, Oct 18, 2011 at 11:06 PM, Eli Bocek-Rivele  wrote:
> Hi all,
> I'm very new to the community and I can only imagine this question has been
> asked before but google searching (and looking in archives) has not helped
> but it may be because I don't know how to correctly phrase the question, but
> here goes. Is there a way to have an expanded view into a repository's
> projects on NFS such that a user can explore it in a shell in a read-only
> fashion? What I mean is if I have a repository like:
>
> file:///repos/myproj/stuff/foo.c
> I'd have on disk
> /svn_explore/repos/myproj/stuff/foo.c

You'd have to keep a checked out working copy of the repos. This can
get very bulky, *VERY* fast, if you have a lot of releases or
autobuild branches, but it's an effective way to keep the code
legible. It can be updated as part of a "post-commit" procedure on the
server, but it can be slow, so I'd actually recommend a cron job, and
there's always a chance it might be in the process of updating when
you look at it. But it's often very effective for providing a place to
review the basic source tree.

> As a set of directories / files that I could look at that are always 'head'
> and are read-only and are kept up to date. I was thinking I
> could orchestrate this with a cron, or maybe some changes to hooks but I was
> wondering if there was an easy supported way or standard way in which people
> do this. This would allow people to look into the 'latest' in the repository
> without actually having to run any svn commands.
> Thanks in advance for any help and I appreciate you reading such a novice
> question. I'm very new to svn but already find it a powerful and promising
> system.
> -Eli
>

Error

[Vjekoslav Jug]

Hello,

I have encountered this error while upgrading working copy to new format.
This happened after I upgraded from 1.6.x.

 



 

Hope this helps,

 

Best regards,

 

Vjekoslav Jug

Infodesign d.o.o.

Tina Ujevića 46, Varaždin

Email:   v...@infodesign.hr

Tel.: +385 (42) 206 609

Mob.: +385 (98) 185 86 22

 

<>

File externals stop working in 1.7

[Krigsman Kristian]

Hi

We have encountered a problem with SVN 1.7 when we are checking out 
(or updating) some of our repositories containing externals. These 
were all functioning in 1.6.17 but seems to have been either broken 
or changed in 1.7. I tried to find any relevant posts regarding the 
error message but couldn't find anything that points to whether this 
is an intended change or a bug.

Script to reproduce is as follows:
---
svnadmin create repo
svn co file://`pwd`/repo wc
cd wc
mkdir -p A/B/C D
echo text > A/B/file
svn add A D
echo ^/A/B E > external.prop
echo ^/A/B/file E/file2 >> external.prop
svn propset svn:externals -F external.prop D
svn ci -mm
cd ..
rm -rf wc
svn co file://`pwd`/repo/D wc
---

In 1.6.17 this results in the following output:
---
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
Checked out revision 0.
$ cd wc
wc$ mkdir -p A/B/C D
wc$ echo text > A/B/file
wc$ svn add A D
A A
A A/B
A A/B/file
A A/B/C
A D
wc$ echo ^/A/B E > external.prop
wc$ echo ^/A/B/file E/file2 >> external.prop
wc$ svn propset svn:externals -F external.prop D
property 'svn:externals' set on 'D'
wc$ svn ci -mm
Adding A
Adding A/B
Adding A/B/C
Adding A/B/file
Adding D
Transmitting file data .
Committed revision 1.
wc$ cd ..
$ rm -rf wc
$ svn co file://`pwd`/repo/D wc
 U   wc

Fetching external item into 'wc/E'
Awc/E/file
Awc/E/C
Checked out external at revision 1.


Fetching external item into 'wc/E/file2'
Ewc/E/file2
Checked out external at revision 1.

Checked out revision 1.
---

But when I try the same in 1.7 I get:
---
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
Checked out revision 0.
wc$ cd wc
wc$ mkdir -p A/B/C D
wc$ echo text > A/B/file
wc$ svn add A D
A A
A A/B
A A/B/file
A A/B/C
A D
wc$ echo ^/A/B E > external.prop
wc$ echo ^/A/B/file E/file2 >> external.prop
wc$ ../svn propset svn:externals -F external.prop D
property 'svn:externals' set on 'D'
wc$ ../svn ci -mm
Adding A
Adding A/B
Adding A/B/C
Adding A/B/file
Adding D
Transmitting file data .
Committed revision 1.
wc$ cd ..
$ rm -rf wc
$ ./svn co file://`pwd`/repo/D wc
 U   wc

Fetching external item into 'wc/E':
Awc/E/file
Awc/E/C
Checked out external at revision 1.


Fetching external item into 'wc/E/file2':
svn: warning: W155022: Cannot insert a file external defined on 'wc' into the 
working copy 'wc/E'.

Checked out revision 1.
---

Right now this prevents us from moving to 1.7 since files are missing from the 
working copy.
Will this be fixed or has the use of externals changed? 

Thanks,
Kristian

The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents
thereof, and is kindly asked to notify the sender and delete the e-mail
immediately.

Exception when updating working base to 1.7

[Ken Pomella]

I just installed Tortoise 1.7 and it told me to upgrade my working base. When I 
try to do so it blows up and gives me the following error.
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
found_md5_checksum))
---
OK
---

How to use get_log along with path kind {file,directory}?

[Yonggang Luo]

rt.

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Re: How to use get_log along with path kind {file,directory}?

[Daniel Shahaf]

Please don't keep re-posting the same question on a daily basis.

The answer is in the manual.

Someone replied to your post with another answer.

罗勇刚(Yonggang Luo)  wrote on Thu, Oct 20, 2011 at 01:33:58 +0800:
> rt.
> 
> -- 
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo

Re: mergeinfo marked not inheritable on sparse checkout

[Douglas Wilson]

On Oct 19, 12:29 am, Johan Corveleyn  wrote:
>
> Is this still the case with 1.7? Could you test that?
>
> There were a lot of merge-tracking improvements and bugfixes in 1.7,
> but I'm not sure if this particular issue has been addressed. 
> Seehttp://subversion.apache.org/docs/release-notes/1.7.html#merge-tracki

I tested with a local repo and TortoiseSVN:
TortoiseSVN 1.7.0, Build 22068 - 64 Bit , 2011/10/10 09:48:29
Subversion 1.7.0,
apr 1.4.5
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.0e 6 Sep 2011
zlib 1.2.5

I'll check the link also. Thanks.

Merging to branches error

[Dimitry Gavrilov]

Hi,

I installed tortoise 1.7 64-bit version on Win 7.

I am getting the below error constantly while trying to commit or merge to 
branches.

What should I do?

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 7393: internal malfunction
---
OK
---

Dimitry Gavrilov
Senior Lead Engineer

[Description: Description: secure_connection2]

<>

RE: assertion fail

[Eric_Nichols]

Thank you Stefan for the reply.

Unfortunately, I am having a much worse issue.  After reinstall of 1.7, my 
machine runs out of memory out when I visit the repo-browser.  TortoiseProc 
uses 25% CPU and constantly increases memory until it crashes.  So, I can't 
download the new source from this avenue.  If there is anything I can do to 
help debug, please let me know.  I'm stuck :(

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Monday, October 17, 2011 3:53 PM
To: Nichols, Eric
Cc: users@subversion.apache.org
Subject: Re: assertion fail

On Mon, Oct 17, 2011 at 02:41:10PM -0700, eric_nich...@mcafee.com wrote:
> This totally hoses my integration... can't do anything useful.  This happens 
> when I do a "SVN Upgrade" on source.  It's failing on source I've never 
> modified before.  Going to install 1.6 and do a clean up on the projects.
> 
> TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
> found_md5_checksum))

Your 1.6 working copy has a bad text-base for some reason and cannot be 
upgraded. Get a fresh checkout with 1.7 and things should be fine.

Strange race-condition/possible bug in Subversion 1.7.0

[Harald Wilhelmi]

Hi,

in the last weeks I developed a little Subversion tool. When I
heard about Subversion 1.7.0 I downloaded the source at the next
opportunity to run the functional tests against the new version.
With the new version two of the tests fail *sometimes*. The
tests use the command line and do about this:
 
echo -n xxx >a   
svn add a 
svn commit -m 'c1' .

svn copy a b
echo -n yyy >b
svn commit -m 'c2' .

Of cause I expect 'b' to contain 'yyy'. However sometimes it
contains 'xxx'. After this the repository is all consistent and fine
in my opinion (expect that 'a' has the unexpected content). However
the working copy looks strange. It behaves like that:

1) 'svn status' and 'svn diff' agree that there is no local change
   in 'b'.

2) If I just do a 'touch' on on 'b' without changing it's content,
   the svn command changes it's opinion. Now 'svn diff' and
   'svn status' agree that there is a local modification (xxx->yyy).

Since I added the equivalent of a 'sleep 1' just after the 'svn copy'
I have not seen the issue again.

Do you consider that a bug?
Is it already a known issue?

So far I have not subscribed to the list, so please answer also to
my personal address.

Regards  
Harald Wilhelmi

Re: Strange race-condition/possible bug in Subversion 1.7.0

[Les Mikesell]

On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
 wrote:
>
>    svn copy a b
>    echo -n yyy >b
>    svn commit -m 'c2' .
>
> Of cause I expect 'b' to contain 'yyy'. However sometimes it
> contains 'xxx'. After this the repository is all consistent and fine
> in my opinion (expect that 'a' has the unexpected content). However
> the working copy looks strange. It behaves like that:
>
> 1) 'svn status' and 'svn diff' agree that there is no local change
>   in 'b'.
>
> 2) If I just do a 'touch' on on 'b' without changing it's content,
>   the svn command changes it's opinion. Now 'svn diff' and
>   'svn status' agree that there is a local modification (xxx->yyy).
>
> Since I added the equivalent of a 'sleep 1' just after the 'svn copy'
> I have not seen the issue again.
>
> Do you consider that a bug?

Svn is going to look at the timestamps (and maybe the length) on the
pristine copy and your visible working copy file and if they match,
assume there are no differences. So you need at least the timestamp
resolution of your filesystem difference between the creation and
change.

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

Re: assertion fail

[Andy Levy]

On Wed, Oct 19, 2011 at 17:31,   wrote:
> Thank you Stefan for the reply.
>
> Unfortunately, I am having a much worse issue.  After reinstall of 1.7, my 
> machine runs out of memory out when I visit the repo-browser.  TortoiseProc 
> uses 25% CPU and constantly increases memory until it crashes.  So, I can't 
> download the new source from this avenue.  If there is anything I can do to 
> help debug, please let me know.  I'm stuck :(

I saw this happen once, but haven't been able to reproduce it.

Repo-Browser is not required to check out from a repository. If you
know the URL, you can use SVN Checkout.

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Monday, October 17, 2011 3:53 PM
> To: Nichols, Eric
> Cc: users@subversion.apache.org
> Subject: Re: assertion fail
>
> On Mon, Oct 17, 2011 at 02:41:10PM -0700, eric_nich...@mcafee.com wrote:
>> This totally hoses my integration... can't do anything useful.  This happens 
>> when I do a "SVN Upgrade" on source.  It's failing on source I've never 
>> modified before.  Going to install 1.6 and do a clean up on the projects.
>>
>> TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
>> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
>> found_md5_checksum))
>
> Your 1.6 working copy has a bad text-base for some reason and cannot be 
> upgraded. Get a fresh checkout with 1.7 and things should be fine.
>

Re: How to use get_log along with path kind {file,directory}?

[Yonggang Luo]

I didn't received the reply, so I repost it, because I am just
subscribe to this list. Btw, can you be more specified, I didn't found
the place how get_log along with path kind.

2011/10/20, Daniel Shahaf :
> Please don't keep re-posting the same question on a daily basis.
>
> The answer is in the manual.
>
> Someone replied to your post with another answer.
>
> 罗勇刚(Yonggang Luo)  wrote on Thu, Oct 20, 2011 at 01:33:58 +0800:
>> rt.
>>
>> --
>>  此致
>> 礼
>> 罗勇刚
>> Yours
>> sincerely,
>> Yonggang Luo
>

-- 
从我的移动设备发送

 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

I means using get_log API to retrieve log information along with path kind (file,path)

[Yonggang Luo]

I didn't found a easy way to do that.

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Re: assertion fail

[Eric_Nichols]

I've tried svn checkout. It didn't seem to work either. I'll try again in the 

On Oct 19, 2011, at 5:00 PM, "Andy Levy"  wrote:

> On Wed, Oct 19, 2011 at 17:31,   wrote:
>> Thank you Stefan for the reply.
>> 
>> Unfortunately, I am having a much worse issue.  After reinstall of 1.7, my 
>> machine runs out of memory out when I visit the repo-browser.  TortoiseProc 
>> uses 25% CPU and constantly increases memory until it crashes.  So, I can't 
>> download the new source from this avenue.  If there is anything I can do to 
>> help debug, please let me know.  I'm stuck :(
> 
> I saw this happen once, but haven't been able to reproduce it.
> 
> Repo-Browser is not required to check out from a repository. If you
> know the URL, you can use SVN Checkout.
> 
>> -Original Message-
>> From: Stefan Sperling [mailto:s...@elego.de]
>> Sent: Monday, October 17, 2011 3:53 PM
>> To: Nichols, Eric
>> Cc: users@subversion.apache.org
>> Subject: Re: assertion fail
>> 
>> On Mon, Oct 17, 2011 at 02:41:10PM -0700, eric_nich...@mcafee.com wrote:
>>> This totally hoses my integration... can't do anything useful.  This 
>>> happens when I do a "SVN Upgrade" on source.  It's failing on source I've 
>>> never modified before.  Going to install 1.6 and do a clean up on the 
>>> projects.
>>> 
>>> TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
>>> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
>>> found_md5_checksum))
>> 
>> Your 1.6 working copy has a bad text-base for some reason and cannot be 
>> upgraded. Get a fresh checkout with 1.7 and things should be fine.
>> 

Re: Release branch merging.

[Gavin "Beau" Baumanis]

Ok - Well now I am confused...

I did:
svn rm /repos/branches/releases/1
cd /repos/branches/releases
svn copy http://myServer/repos/branches/releases/1@1000

Which gave me a new copy of the release branch - as it stood at r1000.
Which subsequently the revision used to create ^/tags/1.0

Now we want to release 1.1 - but am back to having my original issue of 
"everything" being in conflict.
cd /repos/branches/releases
svn merge ^/trunk --dry-run

and everything is reported as a tree-conflict.

I assumed that creating the release branch via svn mechanics and then doing a 
merge into that branch would work seamlessly - but it obviously isn't the case.
Firstly I don't understand why it is in conflict in the first place.

Secondly, when in a feature branch;
cd /repos/branches/feature1
svn  merge ^/trunk

works as expected - and updates my feature branch with all changes made in 
trunk - since the last trunk->feature branch merge operation.

Why is it not working for me in the other directory / branch?


As always - thanks in advance!


Gavin.


On 19/10/2011, at 10:56 PM, Gavin Baumanis wrote:

> Hi There everyone,
> 
> I have trunk, branches and tags. 
> (the "default" repo setup)
> 
> VERY recently we swapped from continuous deployment to having a scheduled 
> release strategy.
> We used to simply cherry-pick or even just OS copy the required changes from 
> trunk to a "special"(to us) branch any change that needed to go to production.
> This special branch was ten simply copied to production.
> 
> Now, we are trying to start the "standard" release strategy,
> Develop on trunk,
> Merge to a release branch,
> Create a tag.
> 
> I genuinely cannot recall how we created the release branch;
> all I know is the symptoms of what I now face - and hope to "correct".
> 
> I did this;
> cd /repos/branches/releases/1
> svn merge ^/trunk --dry-run
> 
> And subsequently got a status report that everything was going to be a 
> conflict.
> So I think it's safe to say that the releases branch was created by an OS 
> copy and not an SVN aware operation.
> 
> is there a pain-free way that I correct my repository to allow for successful 
> trunk -> release branch merging?
> I am thinking of;
> * Deleting the release branch;
> * Recreating the release branch at the revision that the release branch was 
> originally created.
> * Re-merging the single trunk change that was merged to 
> ^/branches/releases/1.0
> 
> Which should bring it to its current state - and match the 1.01 release tag.
> 
> And hopefully now allow me to merge ^/trunk -> ^/branches/releases - which 
> should allow a more pain-free merge for the next release.
> 
> Do I have that right?
> Is there something else I can do that would negate the requirement to 
> recreate the release branch?
> 
> As always  - thanks for your assistance.
> 
> 
> Gavin 'Beau' Baumanis.
> 

Re: Release branch merging.

[Gavin Baumanis]

I hate it how it is only after you have sent the email to the mailing list - 
you realise the error you have made!

The issue lies in the creation of the branch.
In the original email it was created via an OS copy and not a svn command.

In the most recent email, I explained how I did this;
> svn copy http://myServer/repos/branches/releases/1@1000

Which effectively is the same thing that I had when I did the OS copy.
The issue being there is no ancestry between ^/trunk and the release branch.

Everything is now working correctly as I have created the release branch with;
svn copy http://myServer/repos/trunk@1000

a subsequent;
cd /repos/branches/releases
svn merge ^/trunk --dry-run

Now shows only the changes performed on trunk since r1000.


Gavin.


On 20/10/2011, at 5:12 PM, Gavin Beau Baumanis wrote:

> Ok - Well now I am confused...
> 
> I did:
> svn rm /repos/branches/releases/1
> cd /repos/branches/releases
> svn copy http://myServer/repos/branches/releases/1@1000
> 
> Which gave me a new copy of the release branch - as it stood at r1000.
> Which subsequently the revision used to create ^/tags/1.0
> 
> Now we want to release 1.1 - but am back to having my original issue of 
> "everything" being in conflict.
> cd /repos/branches/releases
> svn merge ^/trunk --dry-run
> 
> and everything is reported as a tree-conflict.
> 
> I assumed that creating the release branch via svn mechanics and then doing a 
> merge into that branch would work seamlessly - but it obviously isn't the 
> case.
> Firstly I don't understand why it is in conflict in the first place.
> 
> Secondly, when in a feature branch;
> cd /repos/branches/feature1
> svn  merge ^/trunk
> 
> works as expected - and updates my feature branch with all changes made in 
> trunk - since the last trunk->feature branch merge operation.
> 
> Why is it not working for me in the other directory / branch?
> 
> 
> As always - thanks in advance!
> 
> 
> Gavin.
> 
> 
> On 19/10/2011, at 10:56 PM, Gavin Baumanis wrote:
> 
>> Hi There everyone,
>> 
>> I have trunk, branches and tags. 
>> (the "default" repo setup)
>> 
>> VERY recently we swapped from continuous deployment to having a scheduled 
>> release strategy.
>> We used to simply cherry-pick or even just OS copy the required changes from 
>> trunk to a "special"(to us) branch any change that needed to go to 
>> production.
>> This special branch was ten simply copied to production.
>> 
>> Now, we are trying to start the "standard" release strategy,
>> Develop on trunk,
>> Merge to a release branch,
>> Create a tag.
>> 
>> I genuinely cannot recall how we created the release branch;
>> all I know is the symptoms of what I now face - and hope to "correct".
>> 
>> I did this;
>> cd /repos/branches/releases/1
>> svn merge ^/trunk --dry-run
>> 
>> And subsequently got a status report that everything was going to be a 
>> conflict.
>> So I think it's safe to say that the releases branch was created by an OS 
>> copy and not an SVN aware operation.
>> 
>> is there a pain-free way that I correct my repository to allow for 
>> successful trunk -> release branch merging?
>> I am thinking of;
>> * Deleting the release branch;
>> * Recreating the release branch at the revision that the release branch was 
>> originally created.
>> * Re-merging the single trunk change that was merged to 
>> ^/branches/releases/1.0
>> 
>> Which should bring it to its current state - and match the 1.01 release tag.
>> 
>> And hopefully now allow me to merge ^/trunk -> ^/branches/releases - which 
>> should allow a more pain-free merge for the next release.
>> 
>> Do I have that right?
>> Is there something else I can do that would negate the requirement to 
>> recreate the release branch?
>> 
>> As always  - thanks for your assistance.
>> 
>> 
>> Gavin 'Beau' Baumanis.
>>