mergeinfo on all root files and folders
Hi, We always do merges from the root of the repository. When these merges are done svn always marks up the mergeinfo on all first level files and folders as well as the root folder itself. Is this working as intended? We have had a practice for quite a while, dating back to buggy releases where we periodically delete all mergeinfo except for the root of the repository. I'm wondering whether I should amend the script to leave the first level files and folders intact as it seems that it is impossible to reintegrate a branch without these files and folders having the same mergeinfo as the root of the repository and in the past I have had to patch in the mergeinfo to get reintegrate to work. Can anyone enlighten me on this? Cheers, James
mergeinfo on all root files and folders
Hi, We always do merges from the root of the repository. When these merges are done svn always marks up the mergeinfo on all first level files and folders as well as the root folder itself. Is this working as intended? We have had a practice for quite a while, dating back to buggy releases where we periodically delete all mergeinfo except for the root of the repository. I'm wondering whether I should amend the script to leave the first level files and folders intact as it seems that it is impossible to reintegrate a branch without these files and folders having the same mergeinfo as the root of the repository and in the past I have had to patch in the mergeinfo to get reintegrate to work. Can anyone enlighten me on this? Cheers, James
RE: Help! Subversion Exception!
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?
Behaviour of reintegrate in 1.7.1
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
-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: Good strategies for incorporating an external code drop
-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 " and deleting files with "Only in ". 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.
Sparse branches
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
default ignores
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. Cheers, James
RE: default ignores
-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 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.
RE: default ignores
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 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
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 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 > 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: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)
-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
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: moving files in repobrowser generates mergeinfo
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
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.
svn diff --summarize url encoding
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
[no subject]
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, James<>
RE: 'invalid status for updateting properties' error during reintegrate merge (was: no subject)
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: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
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
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
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
http://svn.apache.org/viewvc?view=revision&revision=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
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=revision&revision=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
empty parent infinite child
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
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: E120104: ra_serf: An error occurred during decompression
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.org<mailto: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
-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 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
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 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
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 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
-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 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
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.s
RE: Reverse merge with 1.8.3 yielded tree conflicts
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.
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
RE: separating out unwanted changes
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.org<mailto: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
Set a repository never ignore files
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
RE: Set a repository never ignore files
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 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*.
RE: Set a repository never ignore files
-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.
