RE: Set a repository never ignore files

[James French]

-Original Message-
From: Andreas Krey [mailto:a.k...@gmx.de] 
Sent: 04 June 2014 17:11
To: James French
Cc: Nico Kadel-Garcia; Andreas Stieger; users@subversion.apache.org
Subject: Re: Set a repository never ignore files

On Wed, 04 Jun 2014 15:50:35 +, James French wrote:
...
 The purpose of the repo in question is to store 3rd party distros. I've lost 
 count of the times over the years that we've fallen foul of files not being 
 checked in and then only finding out later.

Perhaps you shouldn't build releases from the dev's sandbox who forgets the 
checkins, but from a separate sandbox. That way you notice immediately when 
something is missing/not committed.


When I say later I mean that day or the next, picked up by continuous 
integration. Its not always obvious what has happened and can take some time to 
diagnose and get the missing files added. Its an annoyance.

Just had a thought, perhaps the svn devs should be bold enough to not set up 
any ignores by default - noy necessary now there are more powerful ways of 
doing it and it would solve this case.

RE: Set a repository never ignore files

[James French]

Thanks Andreas and Nico.

Shame that's not possible, but I welcome the global-ignores and autoprops stuff.

The purpose of the repo in question is to store 3rd party distros. I've lost 
count of the times over the years that we've fallen foul of files not being 
checked in and then only finding out later.

Oh well.

-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: 04 June 2014 03:44
To: Andreas Stieger
Cc: James French; users@subversion.apache.org
Subject: Re: Set a repository never ignore files

On Tue, Jun 3, 2014 at 8:05 PM, Andreas Stieger andreas.stie...@gmx.de wrote:
 Hello,

 On 03/06/14 11:24, James French wrote:
 I have a repo where I want to force .a files to always get added (ie 
 not ignored), irrespective of any ignore settings in user config 
 files. I am happy to set the repo to not ignore any file, if that is 
 easier. I guess I’m after an svn:global-no-ignore property…

 The repository dictated configuration introduced in 1.8 will only 
 /extend/ the client-side global-ignores configuration setting, not 
 override it. There is no support for enforcing for something /not/ to 
 be ignored, other than through deployed run-time configurations, hooks 
 or simply a project policy. Further, adding a file to version control 
 is still an entirely separate user action from not ignoring it.

One could set a pre-commit hook to review the contents of ..svnignore files. It 
won't prevent some types of oddness with git2svn gateways.
Also, be aware that insisting on hanging onto all the .a files can cause 
considerable growth of your repository, with no graceful way to obliterate 
old files: .a files are unlikely to compress as well as text files, nor to 
function well as a set of diffs, so any continuous integration or frequent 
build environment is likely to grow, *FAST*.

Set a repository never ignore files

[James French]

Morning,

I have a repo where I want to force .a files to always get added (ie not 
ignored), irrespective of any ignore settings in user config files. I am happy 
to set the repo to not ignore any file, if that is easier. I guess I'm after an 
svn:global-no-ignore property...

Using svn 1.8.9.

Cheers,
James

separating out unwanted changes

[James French]

Hi,

I wonder if someone could give me some advice on the following situation. Its 
probably pretty simple but my svn knowledge has dropped off a bit. An unstable 
dev branch was reintegrated and then a bunch of subsequent fixes were made on 
the mainline, mixed in with other development. Stability has still not been 
achieved and its now desirable to rollback all the fixes and the dev branch and 
carry on working on the fixes on another dev branch while normal development 
carries on as usual. I'm thinking, rollback all the bug fix commits and the 
branch reintegration and get that committed. Then create a dev branch and then 
reverse merge the reverted commit onto it? Sound right?

Cheers,
James

RE: separating out unwanted changes

[James French]

Thanks for confirming that Bert. I'd prefer to keep the trunk stable so I've 
recommended the reverse merge approach.

From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: 25 February 2014 10:38
To: James French; users@subversion.apache.org
Subject: RE: separating out unwanted changes

That is one option.

The other option is creating a maintenance branch from the old revision, where 
things were still ok (e.g. right before the reintegrate) and then merging the 
changes from trunk to the branch that you want to keep.

It really depends on whether you want to have 'trunk' to be stable again, or if 
you just want to have access a stable branch while still allowing (unstable) 
development work on trunk.

Bert

From: James French [mailto:james.fre...@naturalmotion.com]
Sent: dinsdag 25 februari 2014 10:51
To: users@subversion.apache.orgmailto:users@subversion.apache.org
Subject: separating out unwanted changes

Hi,

I wonder if someone could give me some advice on the following situation. Its 
probably pretty simple but my svn knowledge has dropped off a bit. An unstable 
dev branch was reintegrated and then a bunch of subsequent fixes were made on 
the mainline, mixed in with other development. Stability has still not been 
achieved and its now desirable to rollback all the fixes and the dev branch and 
carry on working on the fixes on another dev branch while normal development 
carries on as usual. I'm thinking, rollback all the bug fix commits and the 
branch reintegration and get that committed. Then create a dev branch and then 
reverse merge the reverted commit onto it? Sound right?

Cheers,
James

svn: E120104: ra_serf: An error occurred during decompression

[James French]

Hi list,

I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I 
repeated the operation with svn 1.7.8 and it did not occur. The following 
section in the STATUS file looks highly relevant:

* ^/subversion/branches/1.8.x-serf-1.3+-windows
   Allow compiling against serf 1.3 and later on Windows
   Justification:
 Serf 1.3 brings a lot of fixes that we need for 1.8.x stability.
   Notes:
 The dependency handling on Windows was updated for 1.9+, so this
 needs a specific backport patch (r1517123)
   Votes:
 +1: rhuijben, brane

Cheers,
James

RE: E120104: ra_serf: An error occurred during decompression

[James French]

Hmm, actually I made a mistake. The merge was done through our own gui tool 
that actually uses svn 1.8.1 command line. Looks like there are a few serf 
fixes in 1.8.3 but the status entry I found looks very suspicious.

From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: 09 September 2013 12:51
To: James French; users@subversion.apache.org
Subject: RE: E120104: ra_serf: An error occurred during decompression

The current TortoiseSVN is already compiled against serf 1.3 as far as I can 
tell.
(TortoiseSVN uses its own custom build system and this patch just affects the 
build system)

Bert

From: James French [mailto:james.fre...@naturalmotion.com]
Sent: maandag 9 september 2013 13:15
To: users@subversion.apache.orgmailto:users@subversion.apache.org
Subject: svn: E120104: ra_serf: An error occurred during decompression

Hi list,

I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I 
repeated the operation with svn 1.7.8 and it did not occur. The following 
section in the STATUS file looks highly relevant:

* ^/subversion/branches/1.8.x-serf-1.3+-windows
   Allow compiling against serf 1.3 and later on Windows
   Justification:
 Serf 1.3 brings a lot of fixes that we need for 1.8.x stability.
   Notes:
 The dependency handling on Windows was updated for 1.9+, so this
 needs a specific backport patch (r1517123)
   Votes:
 +1: rhuijben, brane

Cheers,
James

RE: svn: E120104: ra_serf: An error occurred during decompression

[James French]

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: 09 September 2013 13:36
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during decompression

On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com 
wrote:
 Hi list,



 I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 
 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur.

This looks very much like the error I ran into during testing of 1.8.3, and 
which spawned the following discussion on the dev-list:

http://svn.haxx.se/dev/archive-2013-08/0386.shtml

(it was with an 'svn export' over plain http of a tag of the subversion project 
itself, but the problem might be the same)

Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in 
the serf http-library (with me trying various patches and reproducing the 
issue), but so far without success.

It's good to know that now I'm not the only one seeing this problem.

Likewise :-)

Can you report your OS version please?

Windows7 x64

Can you reproduce it with Antivirus disabled?

I'm first trying with 1.8.3, then I'll try without antivirus/compression. Takes 
a long time as it's a massive checkout.

Also: I couldn't reproduce the issue with compression disabled, by adding the 
option
--config-option servers:global:http-compression=off
to the command line (or configure that setting in your 'servers'
configuration file). That might be a workaround for you (though it will 
probably make things go a lot slower).

--
Johan

RE: svn: E120104: ra_serf: An error occurred during decompression

[James French]

I tried it again with the 1.8.3 command line and the merge went through...

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: 09 September 2013 13:36
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during decompression

On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com 
wrote:
 Hi list,



 I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 
 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur.

This looks very much like the error I ran into during testing of 1.8.3, and 
which spawned the following discussion on the dev-list:

http://svn.haxx.se/dev/archive-2013-08/0386.shtml

(it was with an 'svn export' over plain http of a tag of the subversion project 
itself, but the problem might be the same)

Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in 
the serf http-library (with me trying various patches and reproducing the 
issue), but so far without success.

It's good to know that now I'm not the only one seeing this problem.

Can you report your OS version please?

Can you reproduce it with Antivirus disabled?

Also: I couldn't reproduce the issue with compression disabled, by adding the 
option
--config-option servers:global:http-compression=off
to the command line (or configure that setting in your 'servers'
configuration file). That might be a workaround for you (though it will 
probably make things go a lot slower).

--
Johan

RE: svn: E120104: ra_serf: An error occurred during decompression

[James French]

I guess the final thing to add is that I was using 1.8.1 collabnet x64 and 
1.7.3 wandisco 1.8.3 (serf 1.3.1). The 1.8.1 version doesn't report which 
version of serf is being used but their changelog indicates it might be 1.2.1:

Version 1.8.1
https://dist.apache.org/repos/dist/dev/subversion/

 Changes to included binaries:
* Subversion upgraded to 1.8.1.
* APR 1.4.8.
* APR-Util 1.5.2.
* Httpd 2.2.25.
* Sqlite3 3.7.17.


Version 1.8.0-2
https://dist.apache.org/repos/dist/dev/subversion/

 Changes to included binaries:
* Subversion upgraded to 1.8.0.
* OpenSSL 1.0.1e.
* Serf 1.2.1.
* Neon removed.

-Original Message-
From: James French [mailto:james.fre...@naturalmotion.com] 
Sent: 09 September 2013 14:03
To: Johan Corveleyn
Cc: users@subversion.apache.org
Subject: RE: svn: E120104: ra_serf: An error occurred during decompression

I tried it again with the 1.8.3 command line and the merge went through...

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: 09 September 2013 13:36
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during decompression

On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com 
wrote:
 Hi list,



 I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 
 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur.

This looks very much like the error I ran into during testing of 1.8.3, and 
which spawned the following discussion on the dev-list:

http://svn.haxx.se/dev/archive-2013-08/0386.shtml

(it was with an 'svn export' over plain http of a tag of the subversion project 
itself, but the problem might be the same)

Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in 
the serf http-library (with me trying various patches and reproducing the 
issue), but so far without success.

It's good to know that now I'm not the only one seeing this problem.

Can you report your OS version please?

Can you reproduce it with Antivirus disabled?

Also: I couldn't reproduce the issue with compression disabled, by adding the 
option
--config-option servers:global:http-compression=off
to the command line (or configure that setting in your 'servers'
configuration file). That might be a workaround for you (though it will 
probably make things go a lot slower).

--
Johan

RE: svn: E120104: ra_serf: An error occurred during decompression

[James French]

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: 09 September 2013 14:13
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during decompression

On Mon, Sep 9, 2013 at 3:02 PM, James French james.fre...@naturalmotion.com 
wrote:
 I tried it again with the 1.8.3 command line and the merge went through...

Okay, I'm happy for you that it worked :-). However, I'm not convinced the 
error is gone. In my case it would also only fail intermittently.
I couldn't reproduce it all the time (it happened perhaps 1 in 4 or 5 attempts).

If you would run into the error again, please let us know ...

(in my case, we were able to reduce the reproduction recipe, by only doing an 
'svn export --depth=immediates 
http://svn.apache.org/repos/asf/subversion/tags/1.8.3/' - within a couple of 
attempts of that export I would run into the issue (I can reproduce it with 
both serf 1.2.1 and 1.3.1). Maybe you can also try exactly this export a couple 
of times?)

Tried it with 1.8.3 wandisco about 20 times and it never failed. Tried it with 
1.8.1 collabnet and it failed first time.
Is the version of serf used dependent on the distro then, and not a core svn 
thing?

--
Johan

Reverse merge with 1.8.3 yielded tree conflicts

[James French]

Hi,

I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts 
when a sync up merge was reverted. I ran the merge again with 1.8.3 to confirm 
the issue and again using 1.7.8 command line (which worked). See the status 
reports below (a bit hacked manually to remove some sensitive stuff but 
hopefully there's enough to get an idea). Looks like a regression.

1.8.3:

D   Common
D   Common\TBCommsNetworkManagement.cpp
D   Common\TBCommsNetworkManagement.h
D   Common\TBCommsSimpleDataManager.h
D   Common\TBDebugDraw.cpp
D   Common\TBDebugDraw.h
D   Common\TBUtilities.cpp
D   Common\TBUtilities.h
D   ProjectData\Scenes\ResponsiveCharacter.mcn
D   ProjectData\Scenes\TestBoneLocking.mcn
A  +ProjectData\win32
  C SceneInteraction
 local dir edit, incoming dir delete upon merge
A  +TBCommsNetworkManagement.cpp
A  +TBCommsNetworkManagement.h
A  +TBCommsSimpleDataManager.h
A  +TBDebugDraw.cpp
A  +TBDebugDraw.h
A  +TBGameCharacter.cpp
A  +TBGameCharacter.h
A  +TBUtilities.cpp
A  +TBUtilities.h
  C TestAnimationOnly
 local dir edit, incoming dir delete upon merge
A  +TestAnimationOnly.cpp
A  +TestAnimationOnly.h
  C TestBareBones
 local dir edit, incoming dir delete upon merge
A  +TestBareBones.cpp
A  +TestBareBones.h
  C TestBoneLocking
 local dir edit, incoming dir delete upon merge
  C TestInverseNetworkControl
 local dir edit, incoming dir delete upon merge
A  +TestInverseNetworkControl.cpp
A  +TestInverseNetworkControl.h
  C TestVaulting
 local dir edit, incoming dir delete upon merge
A  +TestVaulting.cpp
A  +TestVaulting.h
M   gameIntegration_WIN32.vcproj
M   gameIntegration_WIN32.vcxproj
M   gameIntegration_WIN32.vcxproj.filters
M   gameIntegration_WIN32.vs2008.sln
M   gameIntegration_WIN32.vs2010.sln
M   gameIntegration_X360.vcxproj
M   gameIntegration_X360.vcxproj.filters
M   gameIntegration_X360.vs2010.sln
A  +main.cpp
Summary of conflicts:
  Tree conflicts: 11

1.7.8

D   Common
D   Common\TBCommsNetworkManagement.cpp
D   Common\TBCommsNetworkManagement.h
D   Common\TBCommsSimpleDataManager.h
D   Common\TBDebugDraw.cpp
D   Common\TBDebugDraw.h
D   Common\TBUtilities.cpp
D   Common\TBUtilities.h
D   ProjectData\Scenes\ResponsiveCharacter.mcn
D   ProjectData\Scenes\TestBoneLocking.mcn
A  +ProjectData\win32
D   SceneInteraction
D   SceneInteraction\SceneInteraction.cpp
D   SceneInteraction\SceneInteraction.h
D   SceneInteraction\SceneInteraction_WIN32.vcproj
D   SceneInteraction\SceneInteraction_WIN32.vcxproj
D   SceneInteraction\SceneInteraction_WIN32.vcxproj.filters
D   SceneInteraction\SceneInteraction_WIN32.vs2008.bat
D   SceneInteraction\SceneInteraction_WIN32.vs2008.sln
D   SceneInteraction\SceneInteraction_WIN32.vs2010.bat
D   SceneInteraction\SceneInteraction_WIN32.vs2010.sln
D   SceneInteraction\SceneInteraction_X360.vcxproj
D   SceneInteraction\SceneInteraction_X360.vcxproj.filters
D   SceneInteraction\SceneInteraction_X360.vs2010.bat
D   SceneInteraction\SceneInteraction_X360.vs2010.sln
D   SceneInteraction\TBXInput.cpp
D   SceneInteraction\TBXInput.h
D   SceneInteraction\main.cpp
A  +TBCommsNetworkManagement.cpp
A  +TBCommsNetworkManagement.h
A  +TBCommsSimpleDataManager.h
A  +TBDebugDraw.cpp
A  +TBDebugDraw.h
A  +TBGameCharacter.cpp
A  +TBGameCharacter.h
A  +TBUtilities.cpp
A  +TBUtilities.h
D   TestAnimationOnly
D   TestAnimationOnly\TestAnimationOnly.cpp
D   TestAnimationOnly\TestAnimationOnly.h
D   TestAnimationOnly\TestAnimationOnly_WIN32.vcproj
D   TestAnimationOnly\TestAnimationOnly_WIN32.vcxproj
D   TestAnimationOnly\TestAnimationOnly_WIN32.vcxproj.filters
D   TestAnimationOnly\TestAnimationOnly_WIN32.vs2008.bat
D   TestAnimationOnly\TestAnimationOnly_WIN32.vs2008.sln
D   TestAnimationOnly\TestAnimationOnly_WIN32.vs2010.bat
D   TestAnimationOnly\TestAnimationOnly_WIN32.vs2010.sln
D   TestAnimationOnly\TestAnimationOnly_X360.vcxproj
D   TestAnimationOnly\TestAnimationOnly_X360.vcxproj.filters
D   TestAnimationOnly\TestAnimationOnly_X360.vs2010.bat
D   TestAnimationOnly\TestAnimationOnly_X360.vs2010.sln
D   TestAnimationOnly\main.cpp
A  +TestAnimationOnly.cpp
A  +TestAnimationOnly.h
D   TestBareBones
D   TestBareBones\TestBareBones.cpp
D   TestBareBones\TestBareBones.h
D   TestBareBones\TestBareBones_WIN32.vcproj
D   TestBareBones\TestBareBones_WIN32.vcxproj
D   TestBareBones\TestBareBones_WIN32.vcxproj.filters
D   TestBareBones\TestBareBones_WIN32.vs2008.bat
D   TestBareBones\TestBareBones_WIN32.vs2008.sln
D   TestBareBones\TestBareBones_WIN32.vs2010.bat
D   TestBareBones\TestBareBones_WIN32.vs2010.sln
D  

RE: Reverse merge with 1.8.3 yielded tree conflicts

[James French]

Thanks for the explanation Stefan. Glad svn is working properly :-)

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: 09 September 2013 15:55
To: James French
Cc: users@subversion.apache.org
Subject: Re: Reverse merge with 1.8.3 yielded tree conflicts

On Mon, Sep 09, 2013 at 02:37:05PM +0100, James French wrote:
 Hi,
 
 I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts 
 when a sync up merge was reverted. I ran the merge again with 1.8.3 to 
 confirm the issue and again using 1.7.8 command line (which worked). See the 
 status reports below (a bit hacked manually to remove some sensitive stuff 
 but hopefully there's enough to get an idea). Looks like a regression.
 

No, this is a feature, not a regression.
It is listed in CHANGES as:

* tree conflicts on directories detected better during merges (issue #3150)

Short story is that 1.7 was deleting subtrees during merges without considering 
the contents of what was being deleted. Whereas 1.8 flags a tree conflict if 
the subtree being deleted during a merge differs from what the commit being 
merged was deleting on the merge source branch.
This allows you to verify whether the deletion of that subtree is in fact 
desired within the context of the merge target.

In Subversion 1.7, users who were concerned about that had to manually verify 
every deleted subtree before committing the result of a merge.
The purpose of these new tree conflicts flagged by 1.8 is to point out the 
deleted subtrees which might require such manual verification.

In your case, you seem to be fine with the deletion of the affected subtrees. 
So you can run this to resolve the conflict for each subtree, for example:

  svn resolve --accept working SceneInteraction # clear conflict marker
  svn rm SceneInteraction  # delete what should be deleted

In the future, we hope to improve the UI to better guide users during 
interactive resolution of these conflicts.

empty parent infinite child

[James French]

Hi,

If I update a folder with -set-depth=empty and then update a child folder with 
-set-depth=infinity the parent is still reported as having empty depth by svn 
info. This is with svn 1.7.6.

Is this by design? Seems weird to me...

James

RE: svn:eol-style native and reintegrate merge

[James French]

From: James French [james.fre...@naturalmotion.com]
Sent: 04 October 2012 22:39
To: users@subversion.apache.org
Subject: svn:eol-style native and reintegrate merge

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set 
svn:eol-style=native on all source code files, because we develop on Mac and 
PC. When I tried to check in it kept failing on files that had inconsistent 
line endings so I kept fixing them until I was able to check in. So far so 
good. The diff of the checkin showed that files with consistent line endings 
(99% of them) simply had the svn:eol-style=native property on them which is 
what I expected. Now that I come to reintegrate however I have had a shock - it 
has converted all files to unix line endings (and I'm on a PC). We do our sync 
up merges with the --ignore-eol-style style switch (to be honest I'm not sure 
exactly what this does). I tried reintegrating with and without switch and it 
does the same - everything has unix line endings. Maybe its just some weird 
glitch and it won't really change the line endings but I'm too scared to check 
in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James


Thanks Thorsten for your reply, replying here for simplicity.  It is primarily 
a windows codebase and all source code has always had windows line endings. I 
am thoroughly confused. I tried the reintegrate merge with svn 1.6.18. With 
--ignore-eol-style the merge went through with no conflicts and the files in my 
working copy all still had windows line endings (as it should be). However, 
when I did a diff it still showed every line of every file as having changed, 
even though there was no physical difference on disk. When I diff with 
--ignore-eol-style only the svn:eol-style native property changes show up. Why 
is the diff showing line changes? I guess its because its telling me that the 
internal data has been changed to LF line endings. Fair enough. Still seems 
weird that a working copy diff should show this though. I still wonder whether 
this whole native eol thing is going to bite me in the arse later and cause a 
load of conflicts that rattle around the codebase for ages (over the years svn 
has unfortunately taught me to expect this kind of stuff).

What I don't accept though is that svn 1.7 is performing correctly. The merge 
*physically changed* all the source files in my working copy to LF line endings 
on a windows boc. That *cannot* be right.

James

RE: svn:eol-style native and reintegrate merge

[James French]

http://svn.apache.org/viewvc?view=revisionrevision=1355703

Fix a bug in propset which could prevent updating cached values related
   to EOL expansion in wc.db.
   Justification:
 Incorrect behaviour, subtle working copy corruption.
   Votes:
 +1: stsp, rhuijben, philip

This was a 1.7.6 fix and it sounds scarily pertinent


From: James French [james.fre...@naturalmotion.com]
Sent: 05 October 2012 09:58
To: users@subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge


From: James French [james.fre...@naturalmotion.com]
Sent: 04 October 2012 22:39
To: users@subversion.apache.org
Subject: svn:eol-style native and reintegrate merge

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set 
svn:eol-style=native on all source code files, because we develop on Mac and 
PC. When I tried to check in it kept failing on files that had inconsistent 
line endings so I kept fixing them until I was able to check in. So far so 
good. The diff of the checkin showed that files with consistent line endings 
(99% of them) simply had the svn:eol-style=native property on them which is 
what I expected. Now that I come to reintegrate however I have had a shock - it 
has converted all files to unix line endings (and I'm on a PC). We do our sync 
up merges with the --ignore-eol-style style switch (to be honest I'm not sure 
exactly what this does). I tried reintegrating with and without switch and it 
does the same - everything has unix line endings. Maybe its just some weird 
glitch and it won't really change the line endings but I'm too scared to check 
in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James


Thanks Thorsten for your reply, replying here for simplicity.  It is primarily 
a windows codebase and all source code has always had windows line endings. I 
am thoroughly confused. I tried the reintegrate merge with svn 1.6.18. With 
--ignore-eol-style the merge went through with no conflicts and the files in my 
working copy all still had windows line endings (as it should be). However, 
when I did a diff it still showed every line of every file as having changed, 
even though there was no physical difference on disk. When I diff with 
--ignore-eol-style only the svn:eol-style native property changes show up. Why 
is the diff showing line changes? I guess its because its telling me that the 
internal data has been changed to LF line endings. Fair enough. Still seems 
weird that a working copy diff should show this though. I still wonder whether 
this whole native eol thing is going to bite me in the arse later and cause a 
load of conflicts that rattle around the codebase for ages (over the years svn 
has unfortunately taught me to expect this kind of stuff).

What I don't accept though is that svn 1.7 is performing correctly. The merge 
*physically changed* all the source files in my working copy to LF line endings 
on a windows boc. That *cannot* be right.

James

RE: svn:eol-style native and reintegrate merge

[James French]

I've got to the bottom of this now, sort of. Bottom line is that 1.7 seems fine 
after all. Even though all the files changed to UNIX line endings, when I 
committed them they flipped back to windows in my working copy. I think that 
that is very weird and disconcerting behaviour, and it didn't happen in all the 
repositories I tested this in (which is also weird and disconcerting). I still 
think there's an issue here and it could be improved but at the end of the day 
everything seemed to turn out OK. Is there some repo side config that could 
affect this?

From: James French [james.fre...@naturalmotion.com]
Sent: 05 October 2012 12:59
To: users@subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge

http://svn.apache.org/viewvc?view=revisionrevision=1355703

Fix a bug in propset which could prevent updating cached values related
   to EOL expansion in wc.db.
   Justification:
 Incorrect behaviour, subtle working copy corruption.
   Votes:
 +1: stsp, rhuijben, philip

This was a 1.7.6 fix and it sounds scarily pertinent


From: James French [james.fre...@naturalmotion.com]
Sent: 05 October 2012 09:58
To: users@subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge


From: James French [james.fre...@naturalmotion.com]
Sent: 04 October 2012 22:39
To: users@subversion.apache.org
Subject: svn:eol-style native and reintegrate merge

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set 
svn:eol-style=native on all source code files, because we develop on Mac and 
PC. When I tried to check in it kept failing on files that had inconsistent 
line endings so I kept fixing them until I was able to check in. So far so 
good. The diff of the checkin showed that files with consistent line endings 
(99% of them) simply had the svn:eol-style=native property on them which is 
what I expected. Now that I come to reintegrate however I have had a shock - it 
has converted all files to unix line endings (and I'm on a PC). We do our sync 
up merges with the --ignore-eol-style style switch (to be honest I'm not sure 
exactly what this does). I tried reintegrating with and without switch and it 
does the same - everything has unix line endings. Maybe its just some weird 
glitch and it won't really change the line endings but I'm too scared to check 
in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James


Thanks Thorsten for your reply, replying here for simplicity.  It is primarily 
a windows codebase and all source code has always had windows line endings. I 
am thoroughly confused. I tried the reintegrate merge with svn 1.6.18. With 
--ignore-eol-style the merge went through with no conflicts and the files in my 
working copy all still had windows line endings (as it should be). However, 
when I did a diff it still showed every line of every file as having changed, 
even though there was no physical difference on disk. When I diff with 
--ignore-eol-style only the svn:eol-style native property changes show up. Why 
is the diff showing line changes? I guess its because its telling me that the 
internal data has been changed to LF line endings. Fair enough. Still seems 
weird that a working copy diff should show this though. I still wonder whether 
this whole native eol thing is going to bite me in the arse later and cause a 
load of conflicts that rattle around the codebase for ages (over the years svn 
has unfortunately taught me to expect this kind of stuff).

What I don't accept though is that svn 1.7 is performing correctly. The merge 
*physically changed* all the source files in my working copy to LF line endings 
on a windows boc. That *cannot* be right.

James

svn:eol-style native and reintegrate merge

[James French]

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set 
svn:eol-style=native on all source code files, because we develop on Mac and 
PC. When I tried to check in it kept failing on files that had inconsistent 
line endings so I kept fixing them until I was able to check in. So far so 
good. The diff of the checkin showed that files with consistent line endings 
(99% of them) simply had the svn:eol-style=native property on them which is 
what I expected. Now that I come to reintegrate however I have had a shock - it 
has converted all files to unix line endings (and I'm on a PC). We do our sync 
up merges with the --ignore-eol-style style switch (to be honest I'm not sure 
exactly what this does). I tried reintegrating with and without switch and it 
does the same - everything has unix line endings. Maybe its just some weird 
glitch and it won't really change the line endings but I'm too scared to check 
in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James

svn:eol-style native and reintegrate merge

[James French]

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set 
svn:eol-style=native on all source code files, because we develop on Mac and 
PC. When I tried to check in it kept failing on files that had inconsistent 
line endings so I kept fixing them until I was able to check in. So far so 
good. The diff of the checkin showed that files with consistent line endings 
(99% of them) simply had the svn:eol-style=native property on them which is 
what I expected. Now that I come to reintegrate however I have had a shock - it 
has converted all files to unix line endings (and I'm on a PC). We do our sync 
up merges with the --ignore-eol-style style switch (to be honest I'm not sure 
exactly what this does). I tried reintegrating with and without switch and it 
does the same - everything has unix line endings. Maybe its just some weird 
glitch and it won't really change the line endings but I'm too scared to check 
in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James

svn:eol-style native and reintegrate merge

[James French]

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set 
svn:eol-style=native on all source code files, because we develop on Mac and 
PC. When I tried to check in it kept failing on files that had inconsistent 
line endings so I kept fixing them until I was able to check in. So far so 
good. The diff of the checkin showed that files with consistent line endings 
(99% of them) simply had the svn:eol-style=native property on them which is 
what I expected. Now that I come to reintegrate however I have had a shock - it 
has converted all files to unix line endings (and I'm on a PC). We do our sync 
up merges with the --ignore-eol-style style switch (to be honest I'm not sure 
exactly what this does). I tried reintegrating with and without switch and it 
does the same - everything has unix line endings. Maybe its just some weird 
glitch and it won't really change the line endings but I'm too scared to check 
in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James

[no subject]

[James French]

Hi,

Using svn 1.7.6 I've had an error a couple of times on reintegration. Here is 
the scenario:

- A file called checkBackwardsCompatibilty.bat is on trunk and has merge info 
on it (I don't want it to but that's a separate discussion).
- The merge info on this file gets updated regularly as people sync 
up/reintegrate branches (again, I hate this, but separate discussion).
- This file is deleted on a dev branch.
- Reintegrate dev branch.

= Error Can't set properies on 'trunk\checkBackwardsCompatibility.bat': 
invalid status for updating properties.

I'm pretty sure I had the same sort of error as the one I'm describing here 
when I synced up from trunk too.

It does not seem to have broken anything catastrophically, but I don't like it. 
I've been using 1.7.5/1.7.6 for a while now and this seems to be the main 
wrinkle, except for getting wc.db into a bad state and not knowing how to 
recover.

I've attached a screenshot from tortoisesvn.

Cheers,
Jamesattachment: svn_cant_set_property.png

RE: 'invalid status for updateting properties' error during reintegrate merge (was: no subject)

[James French]

From: Stefan Sperling [s...@elego.de]
Sent: 28 August 2012 15:03
To: James French
Cc: users@subversion.apache.org
Subject: Re: 'invalid status for updateting properties' error during 
reintegrate merge  (was: no subject)

On Tue, Aug 28, 2012 at 01:15:08PM +0100, James French wrote:
 Hi,

 Using svn 1.7.6 I've had an error a couple of times on reintegration. Here is 
 the scenario:

 - A file called checkBackwardsCompatibilty.bat is on trunk and has merge info 
 on it (I don't want it to but that's a separate discussion).
 - The merge info on this file gets updated regularly as people sync 
 up/reintegrate branches (again, I hate this, but separate discussion).
 - This file is deleted on a dev branch.
 - Reintegrate dev branch.

 = Error Can't set properies on 'trunk\checkBackwardsCompatibility.bat': 
 invalid status for updating properties.

 I'm pretty sure I had the same sort of error as the one I'm describing here 
 when I synced up from trunk too.

 It does not seem to have broken anything catastrophically, but I don't like 
 it. I've been using 1.7.5/1.7.6 for a while now and this seems to be the main 
 wrinkle, except for getting wc.db into a bad state and not knowing how to 
 recover.

 I've attached a screenshot from tortoisesvn.

Hi James,

Can you provide a more detailed recipe that shows how to reproduce
the problem starting from an empty repository and running Subversion
operations on it?

If you like you can use the script below as a starting point.
The interesting part is marked with a comment saying:
  # List of steps starts here
Currently this fails to reproduce your problem. Can you show me what
additional steps need to be done to trigger the error? Thanks!

#!/bin/sh

set -e

cwd=`pwd`
basename=`basename $0`
scratch_area=`echo $basename | sed -e s/\.sh$//`
repos=$scratch_area/repos
trunk=$scratch_area/trunk
branch=$scratch_area/branch
trunk_url=file:///$cwd/$repos/trunk
branch_url=file:///$cwd/$repos/branch

set -x

rm -rf $scratch_area
mkdir -p $scratch_area

mkdir -p $trunk
echo alpha  $trunk/alpha
echo beta  $trunk/beta
mkdir $trunk/gamma
echo delta  $trunk/gamma/delta
mkdir $trunk/epsilon
echo zeta  $trunk/epsilon/zeta

svnadmin create $cwd/$repos
svn import $trunk $trunk_url -m importing project tree
svn copy $trunk_url $branch_url -m creating branch
rm -rf $trunk
svn checkout $trunk_url $trunk
svn checkout $trunk_url ${trunk}2
svn checkout $branch_url $branch

# List of steps starts here

svn ps foo bar $trunk/alpha
svn commit $trunk -m set prop

svn merge $trunk_url $branch
svn commit $branch -m merge from trunk

svn rm $branch/alpha
svn commit $branch -m delete from branch

svn update $trunk
svn merge --reintegrate $branch_url $trunk



Thanks ever so much for getting me started on this Stefan. I know its lame but 
I only have 2 days before going on holiday and I won't have time to try and 
reproduce this. I have made a note in our bug tracker to tell me to pick this 
up. Thanks for your help.

svn diff --summarize url encoding

[James French]

Hi,

I just noticed that svn 1.6 did not url encode the output of svn diff 
-summarize (ie spaces in files not replaced with %20), whereas svn 1.7 does. 
There is nothing in changes.txt about it. Is the 1.7 behaviour correct?

Cheers,
James

RE: moving files in repobrowser generates mergeinfo

[James French]

From: Stefan Sperling [s...@elego.de]
Sent: 25 June 2012 18:59
To: James French; users@subversion.apache.org
Subject: Re: moving files in repobrowser generates mergeinfo

On Mon, Jun 25, 2012 at 07:55:05PM +0200, Stefan Sperling wrote:
 On Mon, Jun 25, 2012 at 05:26:24PM +0100, James French wrote:
  Hi group,
 
  I know this could be seen as a tortoise svn question, but I was wondering 
  if there was anything in subversion itself that would want to put merge 
  info on files moved via a repo browser (1.6 and 1.7). This does not happen 
  when doing moves client side (tortoise or command line).
 
  Cheers,
  James

 See Paul Burba's explanation at
 http://svn.haxx.se/users/archive-2010-11/0466.shtml

Actually, this link is better because haxx.se messes up ascii graphs:
http://mail-archives.apache.org/mod_mbox/subversion-users/201011.mbox/%3CAANLkTin0xJwxg78rU-83QafOt-bcfgML_pB2AHWt2z1s%40mail.gmail.com%3E



Thanks Stefan. I wish it didn't add that mergeinfo. Actually if mergeinfo was 
entirely internal I wouldn't care what it did (as long as it worked). Its all 
the checkin clutter that upsets me.

RE: moving files in repobrowser generates mergeinfo

[James French]

From: Stefan Sperling [s...@elego.de]
Sent: 26 June 2012 10:06
To: James French
Cc: users@subversion.apache.org
Subject: Re: moving files in repobrowser generates mergeinfo

On Tue, Jun 26, 2012 at 09:47:06AM +0100, James French wrote:
 Thanks Stefan. I wish it didn't add that mergeinfo. Actually if mergeinfo was 
 entirely internal I wouldn't care what it did (as long as it worked). Its all 
 the checkin clutter that upsets me.

How much clutter do you have? If you're using 1.7 it shouldn't be all
that bad anymore, see 
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording


Quite a lot has built up. We're not using 1.7 yet. I am doing preliminary 
testing/upgrading scripts etc. I will also delete all non-root merge info. My 
hope is to get to a situation where mergeinfo only exists on the root as we 
always merge from the root. 1.7 will help things I am sure but it still seems 
that mergeinfo will probably still creep in due to per-file merges to resolve 
tree conflicts where people forget to check 'ignore ancestry', and through 
repobrowser renaming. I am hoping 1.8 will resolve the first of these issues.

RE: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)

[James French]

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: 25 June 2012 15:41
To: Attila Nagy
Cc: Philip Martin; users@subversion.apache.org
Subject: Re: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)

On Mon, Jun 25, 2012 at 04:33:50PM +0200, Attila Nagy wrote:
 ps: I hope trunk is stable enough now for general daily usage... :)

No, not yet. Unless you want to help out with development and/or testing please 
do not run trunk code until released as 1.8.0.


May I ask when 1.8 is expected (very roughly)?

moving files in repobrowser generates mergeinfo

[James French]

Hi group,

I know this could be seen as a tortoise svn question, but I was wondering if 
there was anything in subversion itself that would want to put merge info on 
files moved via a repo browser (1.6 and 1.7). This does not happen when doing 
moves client side (tortoise or command line).

Cheers,
James

RE: default ignores

[James French]

Sorry for late reply - thanks for that information Johan. Glad that there's 
work going on in this area :)

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: 18 April 2012 16:32
To: James French
Cc: Les Mikesell; Subversion Users
Subject: Re: default ignores

On Wed, Apr 18, 2012 at 10:00 AM, James French james.fre...@naturalmotion.com 
wrote:

 
 From: Les Mikesell [lesmikes...@gmail.com]
 Sent: 17 April 2012 19:34
 To: James French
 Cc: Subversion Users
 Subject: Re: default ignores

 On Tue, Apr 17, 2012 at 1:08 PM, James French 
 james.fre...@naturalmotion.com wrote:

 I would say that it is up to the user to check their commit and if it 
 contains unwanted files then that fact should be visible to them and they 
 can un-add them and set up an ignore if appropriate.

 Sorry, but no.  A user can't ever un-add something he has committed to 
 a repository.  And it is an unreasonable amount of admin time/work for 
 the administrator to do it with an svnadmin dump/filter/load cycle.

 Silently failing to add important files I think is worse because you simply 
 don't know that its happened until something goes wrong later.

 But you just said the user was supposed to check...  It is easy to add 
 the missed files, but you can't un-add.

 I still believe that svn is a source control system that each user must take 
 responsibility for and configure how they want.

 Of course, but defaults should be there for the common case.

 I don't think that config decisions should be taken by the core product. 
 What if a '.a' file means something else on a different platform? Its the 
 arbitrary nature of the excludes I don't like either (ie primarily supports 
 the svn dev's main platform).

 That's why it is in a config file, not hardcoded.  Make it do whatever 
 you want.  Perhaps the clients should make it easier to see the config 
 and change it instead of just dropping a normally hidden file 
 somewhere, but that doesn't make having defaults wrong or less useful.

 One could organise it so the build trees are separate to source trees which 
 completely gets round the problem of accidentally checking in object 
 files... This is what I've got but I'm being penalised because other people 
 mix their build output files in with their source.

 There is a worse problem of committing binaries in the mix, especially 
 if you combine a lot of projects in one repository.   How big can the 
 repository potentially grow and how long do you want to be down when 
 the time comes to rearrange or clean it up with some dump/load passes?
  Or can we just expect hardware speed and capacity to stay ahead of 
 this problem forever?

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


 Fair points. In my first point I did mean pre-commit though. I certainly take 
 your point about irreversible repository bloat though. I think we both agree 
 that a *per-repository* central config system would be great. Then I could 
 have all the lovely ignores on the repositories that contain source code and 
 no ignores on the repositorys that contain SDKs, 3rd party distros, artwork, 
 animation resources etc etc (where it can really hurt when you've got twenty 
 artists plowing stuff in that don't know much about subversion). That's what 
 I really need. Unless its per-repository the problem always remains.


You may be interested to know that work is being done currently on inheritable 
properties, with amongst others the goal of enabling repository dictated 
configuration (with svn:ignore or global-ignores definitely on the radar as a 
concrete use case). It's too early to tell how it will turn out concretely, and 
when it will be finished.
But I'd just thought of letting you know that there may be some improvement on 
the horizon.

See this design doc on the wiki:
http://wiki.apache.org/subversion/InheritedProperties

And a dev-thread with lots of discussion (note: it's a long thread, but 
contains some interesting discussions and ideas, amongst others about the 
ignore property):
http://svn.haxx.se/dev/archive-2012-01/0032.shtml

Paul Burba is currently working on a feature branch to see how the current 
design (see wiki) turns out in practice:
http://svn.apache.org/viewvc/subversion/branches/inheritable-props/

--
Johan

RE: default ignores

[James French]

From: Les Mikesell [lesmikes...@gmail.com]
Sent: 17 April 2012 19:34
To: James French
Cc: Subversion Users
Subject: Re: default ignores

On Tue, Apr 17, 2012 at 1:08 PM, James French
james.fre...@naturalmotion.com wrote:

 I would say that it is up to the user to check their commit and if it 
 contains unwanted files then that fact should be visible to them and they can 
 un-add them and set up an ignore if appropriate.

Sorry, but no.  A user can't ever un-add something he has committed to
a repository.  And it is an unreasonable amount of admin time/work for
the administrator to do it with an svnadmin dump/filter/load cycle.

 Silently failing to add important files I think is worse because you simply 
 don't know that its happened until something goes wrong later.

But you just said the user was supposed to check...  It is easy to add
the missed files, but you can't un-add.

 I still believe that svn is a source control system that each user must take 
 responsibility for and configure how they want.

Of course, but defaults should be there for the common case.

 I don't think that config decisions should be taken by the core product. What 
 if a '.a' file means something else on a different platform? Its the 
 arbitrary nature of the excludes I don't like either (ie primarily supports 
 the svn dev's main platform).

That's why it is in a config file, not hardcoded.  Make it do whatever
you want.  Perhaps the clients should make it easier to see the config
and change it instead of just dropping a normally hidden file
somewhere, but that doesn't make having defaults wrong or less useful.

 One could organise it so the build trees are separate to source trees which 
 completely gets round the problem of accidentally checking in object files... 
 This is what I've got but I'm being penalised because other people mix their 
 build output files in with their source.

There is a worse problem of committing binaries in the mix, especially
if you combine a lot of projects in one repository.   How big can the
repository potentially grow and how long do you want to be down when
the time comes to rearrange or clean it up with some dump/load passes?
  Or can we just expect hardware speed and capacity to stay ahead of
this problem forever?

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


Fair points. In my first point I did mean pre-commit though. I certainly take 
your point about irreversible repository bloat though. I think we both agree 
that a *per-repository* central config system would be great. Then I could have 
all the lovely ignores on the repositories that contain source code and no 
ignores on the repositorys that contain SDKs, 3rd party distros, artwork, 
animation resources etc etc (where it can really hurt when you've got twenty 
artists plowing stuff in that don't know much about subversion). That's what I 
really need. Unless its per-repository the problem always remains.
 

RE: default ignores

[James French]

-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com] 
Sent: 17 April 2012 16:57
To: James French
Cc: Subversion Users
Subject: Re: default ignores

On Tue, Apr 17, 2012 at 10:18 AM, James French james.fre...@naturalmotion.com 
wrote:
 Hi group,



 Just wanted to have a bit of rant about the default ignores that 
 subversion clients have since its cost us so much time and hassle. I 
 would like to argue that there should be no default ignores - let the 
 client (customer) deal with it.



 The '.a' ignore has particularly hurt us. I've lost count of the times 
 that developers have checked in third party SDKs into a 'buildtools' 
 type repository only to later find out that a load of .a files were 
 missing. I just think its a terrible default.



 The latest thing to hit us was in our build scripts that do drops from 
 a perforce repo and create vendor branches etc, which has messed up 
 the vendor branches because a script somewhere was not correctly 
 countermanding the default ignores.



 This has happened so many times to so many developers over the years 
 that I felt I should say something.



 Anyone else agree?



 It would be lovely to be able to set up ignores centrally too without 
 relying on individual devs to get it right.

I'd argue that it would be much worse to automatically include common build 
results for the bazillion commits that don't want them than to have to 
explicitly mention them in the one commit where you might.  I might change my 
mind about that if subversion ever adds a reasonable way to remove something 
from a repository, but that seems more and more unlikely.

Defaults aren't ever going to suit everyone.  Change them if you don't
like them - that's why you get your own copy.   And I'd also argue
that centrally managed default templates for initial user setup would be a good 
thing, but the user should be able to make the final version suitable for his 
own purposes.  As you say, 'let the client deal with it' - but keep the 
defaults correct for the common case.




Yeah, I think the best is a centrally manageable but user overridable system.

I would say that it is up to the user to check their commit and if it contains 
unwanted files then that fact should be visible to them and they can un-add 
them and set up an ignore if appropriate. Silently failing to add important 
files I think is worse because you simply don't know that its happened until 
something goes wrong later. I still believe that svn is a source control system 
that each user must take responsibility for and configure how they want. I 
don't think that config decisions should be taken by the core product. What if 
a '.a' file means something else on a different platform? Its the arbitrary 
nature of the excludes I don't like either (ie primarily supports the svn dev's 
main platform).

One could organise it so the build trees are separate to source trees which 
completely gets round the problem of accidentally checking in object files... 
This is what I've got but I'm being penalised because other people mix their 
build output files in with their source.

One last point is that svn is about much more than just source code these days 
so these default ignores just seem a bit outdated now to me.

Sparse branches

[James French]

Hi,

I understand sparse checkouts but is there a recommended way of doing 'sparse 
branches'? Often projects need to be farmed out to a release branch and then 
deleted from the main trunk (to save space). It is then necessary to do the 
inverse on the new branch ie delete all the projects that are not necessary on 
the branch (obviously its not necessary but its nicer for performance and disk 
space).

Is this the only way of doing it or is it possible to be cleverer with the copy 
so that only the minimum is copied in the first place? Could a simple merge 
relationship be maintained if the project was not deleted from the trunk? (I 
worry about mergeinfo...)

Cheers,
James

RE: Good strategies for incorporating an external code drop

[James French]

-Original Message-
From: KARR, DAVID [mailto:dk0...@att.com] 
Sent: 08 November 2011 20:31
To: users@subversion.apache.org
Subject: Good strategies for incorporating an external code drop

Subversion works fine when developers have access to the SVN repo.  I'm working 
on a project where one of the developers for one of the projects doesn't have 
access to our network.  When he makes changes he sends me a zip file with the 
new contents of the project.

When I incorporate his changes, I've been going through a somewhat manual 
process, doing a diff -cr between the old and new, copying in files that have 
changes, copying in new files with Only in new and deleting files with 
Only in old.

Is there an easier way to do this?



I'd try and change it so he does have access, restricted to just subversion if 
that's the issue. Then you can use permissions to lock him down to a specific 
dev branch. Much easier.

Behaviour of reintegrate in 1.7.1

[James French]

Hi guys,

Firstly, thanks for all the enormous effort on svn 1.7.x, and for all the great 
support. I have high hopes for 1.7. Its great to see all those .svn folders 
banished.

I was prompted to give 1.7.1 a shot when a reintegrate merge task turned up 
where the destination checkout was sparse, which was not possible at all in 
1.6. If memory serves me correctly with 1.6 you could reintegrate into you 
working copy provided that the development branch had been fully synced up to 
the same revision as the working copy. Once the reintegration was complete you 
could update to merge in any further checkins and then checkin yourself. Am I 
correct in this?

With 1.7.1 (tortoisesvn), it seemed that this might not be the case. The dev 
branch was synced up to revision 10769 and the destination working copy was 
alsio at 10769 (using update to revision). When I tried to reintegrate svn 
complained that revisions beyond the revision of the working copy had not been 
synced up, and as other people checked in this number appeared to grow.

I did not look much further than this, but this seemed fishy so I thought I'd 
ask here. We're used to loads of hassle with mergeinfo and reintegrate merges 
(this is one area I'm praying that svn 1.7 will greatly improve). The merge 
info has been such a headache over the last few years that we're all a bit 
confused as to what's correct, what's buggy, what's left over from previous 
bugs...

Oh I should say that this is using server version 1.6.17 and the merging was 
performed on Windows 7.

Cheers,
James

RE: Behaviour of reintegrate in 1.7.1

[James French]

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: 26 October 2011 11:29
To: James French
Cc: users@subversion.apache.org
Subject: Re: Behaviour of reintegrate in 1.7.1

On Wed, Oct 26, 2011 at 10:02:17AM +0100, James French wrote:
 I was prompted to give 1.7.1 a shot when a reintegrate merge task
 turned up where the destination checkout was sparse, which was not
 possible at all in 1.6. If memory serves me correctly with 1.6 you
 could reintegrate into you working copy provided that the development
 branch had been fully synced up to the same revision as the working
 copy.

This is correct.

 Once the reintegration was complete you could update to merge in
 any further checkins and then checkin yourself.

Not sure what you mean here, this is very unclear.
Update which working copy?
Merge further revisions from which branch to where?


After you've merged into working copy you can't check in until that working 
copy is up to date, hence updating to get latest changes which are then 'merged 
in' to your working copy. I shouldn't have used the term 'merge' as it was 
confusing.

Am I correct in this?

See
http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3c20110720124721.ga7...@ted.stsp.name%3E
for a more precise explanation.


Thanks. I solved my immediate problem by doing a 2 way merge and bypassing the 
reintegrate checking.

 With 1.7.1 (tortoisesvn), it seemed that this might not be the case.
 The dev branch was synced up to revision 10769 and the destination
 working copy was alsio at 10769 (using update to revision). When I
 tried to reintegrate svn complained that revisions beyond the revision
 of the working copy had not been synced up, and as other people
 checked in this number appeared to grow.

No idea. Can you please show the exact error message you got?


Sorry, its gone. It was a load of missing revisions on a load of different 
files and folders. 


From where I stand it sounds as if you simply haven't closed all gaps
in the revision ranges already synced from trunk to the branch.

But maybe this is a separate problem related to the sparse working copy?
Can you show us how to reproduce the problem starting from an empty
test repository?


I'm not really in a position to do that right now but as I evaluate 1.7 I 
intend to build up a test suite so I can really get to grips with how things 
are working. Sorry about that, its a bit lame but work deadlines and all...


 I did not look much further than this, but this seemed fishy so I
 thought I'd ask here. We're used to loads of hassle with mergeinfo and
 reintegrate merges (this is one area I'm praying that svn 1.7 will
 greatly improve). The merge info has been such a headache over the
 last few years that we're all a bit confused as to what's correct,
 what's buggy, what's left over from previous bugs...

I hope that 1.7 will improve things for you.
Note that benefits are most visible with branches created and
maintained exclusively with 1.7 clients.


I am sure it will. Thanks for all your help, and for tortoisesvn.

RE: Help! Subversion Exception!

[James French]

Upgrading to svn 1.7 whose principal feature is a major change to the working 
copy, with local mods, is just plain dumb.

From: Igor d [mailto:igoro...@gmail.com]
Sent: 18 October 2011 15:20
To: Igor d; users@subversion.apache.org
Subject: Re: Help! Subversion Exception!

But if i have a lot of different local modifications in sources, you propose me 
to checkout??? You are crazy?