Re: svn: E235000: error when performin a svn switch with SVN 1.7.4
Derek Wallace writes: > We use SVN switch command to "switch" between different TAGs for a folder. > > This has being working fine with 1.6.x. However now with 1.7.4 it produces a > SVN error. > > U models/micron/MT49H32M18C/ReleaseNotes.txt > U models/micron/MT49H32M18C/modulerelease.tcl > U models/micron/MT49H32M18C/rldram2.v > U models/micron/MT49H32M18C/ReleaseDiff.log > D models/cypress/CY7C1512V18/ReleaseNotes.txt > D models/cypress/CY7C1512V18/modulerelease.tcl > D models/cypress/CY7C1512V18/ReleaseDiff.log > svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line 1583: > assertion failed (action == svn_wc_conflict_action_edit || action == > svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) > > > The next file to be checked out is **probably** a Linux soft link and this we > think is what triggers the error. > > The file links to a file that is a subfolder of the folder CY7C1512V18 > i.e. > CY7C1512V18.vhd is a link to vhdl/CY7C1512V18.vhd > > > > Ive tried to create a small recipe to reproduce the problem but havnt been > able to. > > What further information can I provide to help diagnose this issue. Is it reproducible: if you start with a fresh checkout can you reproduce the error? Is it reproducible on a subset of the working copy: if you checkout "cypress" rather than "models" can you reproduce the error? Please describe the changes made by the switch. Running svn diff --summarive URL_OF_WC URL_OF_SWITCH_TARGET may help. -- Philip
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: svn: E235000: error when performin a svn switch with SVN 1.7.4
Philip Martin writes: > Please describe the changes made by the switch. Running > > svn diff --summarive URL_OF_WC URL_OF_SWITCH_TARGET > > may help. I think I may have identified it: svnadmin create repo svn import repo/format -mm file://`pwd`/repo/A/f svn co file://`pwd`/repo wc ln -s f wc/A/g svn add wc/A/g svn ci -mm wc svn pd svn:special wc/A/g rm wc/A/g touch wc/A/g svn ci -mm wc svn up wc svn up -r2 wc svn: E235000: In file '../src-1.7/subversion/libsvn_wc/update_editor.c' line 1583: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) The problem is a file that gains or loses svn:special, thus changing to or from a symlink, without the node being replaced. -- Philip
Re: svn: E235000: error when performin a svn switch with SVN 1.7.4
Philip Martin writes: > Philip Martin writes: > >> Please describe the changes made by the switch. Running >> >> svn diff --summarive URL_OF_WC URL_OF_SWITCH_TARGET >> >> may help. > > I think I may have identified it: > > svnadmin create repo > svn import repo/format -mm file://`pwd`/repo/A/f > svn co file://`pwd`/repo wc > ln -s f wc/A/g > svn add wc/A/g > svn ci -mm wc > svn pd svn:special wc/A/g > rm wc/A/g > touch wc/A/g > svn ci -mm wc > svn up wc > svn up -r2 wc > svn: E235000: In file '../src-1.7/subversion/libsvn_wc/update_editor.c' line > 1583: assertion failed (action == svn_wc_conflict_action_edit || action == > svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) > > The problem is a file that gains or loses svn:special, thus changing to > or from a symlink, without the node being replaced. An ugly workaround is to delete the problem file to provoke a tree conflict: svn cleanup wc svn rm wc/A/g svn up -r2 svn revert wc/A/g This does require that you identify the problem file. -- Philip
AW: Info about SVN
Hello Andre! You were already told that subversion does only parts of what you need. Maybe have a look at Redmine for web access, tickets, workflows, email notification and such things. It's integration with subversion is really good. It has WIKI and forum facilites as well. It is still no content management system with XML capabilities, but it will happily manage the files and issues of the CM system of your choice for you. Mit freundlichen Grüßen Dr. Hartmut Niemann Von: Balta, Andre [mailto:andre.ba...@cubic.com] I am an engineer for cubic defense applications and we are considering using your software for a potential program. I have a list of requirement that my information management software needs to do. I was hoping you could confirm if SVN can or cant do the following: · Assign authorized users with groups, roles and permissions (CRUD) · Web based view and interface · Support TLS/SSL · Support digital signatures (certificates/CAC) · Support Content management o XML documents o XSLT (transforms) o Cascading Style sheets o 3D models (COLLADA) - view or javascript o Serve Javascript enabled web pages · Support creation of task items, assignment to action officers, suspense date and status · Support version control of content (tied to issues) · Support workflow for content · User defined workflow schemas · Automated promotion based on criteria · User promotion limited by access · Support e-mail notification on state change
Subversion mangling passwords to apache over https
Folks, This is a follow up to the thread `Need help troubleshooting user authentication (apache)`: http://subversion.markmail.org/thread/q57ffzbhrdv6ydhp ...with the hope of catching a few more eyeballs. Quick Summary: subversion (both TortoiseSVN and the command-line client provided by TSVN) is changing certain characters whilst using Basic Authentication (over https, from Windows XP) to apache 2.2 (on Windows Server 2003). So far I have confirmed this for the UK keyboard `£` (SHIFT-3): > When using a browser, I get the following for -1 > through -0 on my UK keyboard (bounded by '[]'): > > 2012-04-17 16:03:09.734000 : svntest [!"£$%^&*()] > > ...but when I use the svn command line client I log instead: > > 2012-04-17 16:01:52.124000 : svntest [!"œ$%^&*()] > > Note that the `£` is now different. I think that this explains > the `Password Mismatch` error? Philip Martin has already responded (thanks!) with: > Non-ascii passwords are a problem for HTTP because there is > no standard for encoding the password before constructing the > digest, nor is there a standard for the client to tell the > server which encoding it used. Because there is no standard > clients tend to do different things. Some clients will > convert the password to UTF-8, some clients will convert to > some other encoding, and some clients will leave it in whatever > encoding the user entered. ...which helps to explain the problem (except we are using `basic` plain text, not digest) but I cannot believe that we are the only subversion users with this problem, what about other users with non-latin character sets (Russia, Israel etc)? How can I help to narrow this down? Is it likely to be Windows specific (I don't have any *nix flavour available) or something to do with serf or neon (instead of svn proper)? Should I file a bug report (I get no relevant hits when I search for 'password')? Regards, ~ mark c Subversion client (on corporate Windows XP Pro SP3 using UK regional settings): D:\>svn --version svn, version 1.7.4 (r1295709) compiled Mar 8 2012, 18:47:27 Copyright (C) 2012 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Server is Windows Server 2003 Std (in VMWare) also using UK regional settings: apache 2.2.22 (Win32) DAV/2 mod_ssl/2.2.22 OpenSSL/0.9.8t mod_wsgi/3.3 Python/2.6.6 SVN/1.7.4 I am using the svn binaries from alagazam but I don't think they are involved as the password is being rejected by LDAP lookup before DAV gets a look-in, from a site-wide ... block (there are more config details in the referenced thread).
RE: svn: E235000: error when performin a svn switch with SVN 1.7.4
Hi Philip, Thanks for looking into this. Im trying to create a simple recipe to illustrate the problem. While I was creating the recipe this happened. # Currently I have derek1.txt as a file [derek.wallace@dublogon1 svn_links]$ l total 16 drwxrwxr-x 3 derek.wallace Intune Staff 1024 Apr 18 12:26 . drwxrwxr-x 17 derek.wallace Intune Staff 2048 Apr 16 11:57 .. -rw-rw-r-- 1 derek.wallace Intune Staff0 Apr 16 12:17 derek1.txt drwxrwxr-x 2 derek.wallace Intune Staff 80 Apr 18 12:26 folder1 # Delete the file [derek.wallace@dublogon1 svn_links]$ rm derek1.txt # Create Link with the same name [derek.wallace@dublogon1 svn_links]$ ln -s folder1/derek1.txt [derek.wallace@dublogon1 svn_links]$ l total 16 drwxrwxr-x 3 derek.wallace Intune Staff 1024 Apr 18 12:27 . drwxrwxr-x 17 derek.wallace Intune Staff 2048 Apr 16 11:57 .. lrwxrwxrwx 1 derek.wallace Intune Staff 18 Apr 18 12:27 derek1.txt -> folder1/derek1.txt drwxrwxr-x 2 derek.wallace Intune Staff 80 Apr 18 12:26 folder1 # Tran and commit. [derek.wallace@dublogon1 svn_links]$ svn ci -m "" svn: E145001: Commit failed (details follow): svn: E145001: Entry '/scratch-disk4/derek.wallace/IVX8000_trunk_FPGA/test/svn_links/derek1.txt' has unexpectedly changed special status [derek.wallace@dublogon1 svn_links]$ Ill continue to try and create the receipe. Thx Derek -Original Message- From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of Philip Martin Sent: 18 April 2012 09:24 To: Derek Wallace Cc: users@subversion.apache.org Subject: Re: svn: E235000: error when performin a svn switch with SVN 1.7.4 Philip Martin writes: > Philip Martin writes: > >> Please describe the changes made by the switch. Running >> >> svn diff --summarive URL_OF_WC URL_OF_SWITCH_TARGET >> >> may help. > > I think I may have identified it: > > svnadmin create repo > svn import repo/format -mm file://`pwd`/repo/A/f svn co > file://`pwd`/repo wc ln -s f wc/A/g svn add wc/A/g svn ci -mm wc svn > pd svn:special wc/A/g rm wc/A/g touch wc/A/g svn ci -mm wc svn up wc > svn up -r2 wc > svn: E235000: In file > '../src-1.7/subversion/libsvn_wc/update_editor.c' line 1583: assertion > failed (action == svn_wc_conflict_action_edit || action == > svn_wc_conflict_action_delete || action == > svn_wc_conflict_action_replace) > > The problem is a file that gains or loses svn:special, thus changing > to or from a symlink, without the node being replaced. An ugly workaround is to delete the problem file to provoke a tree conflict: svn cleanup wc svn rm wc/A/g svn up -r2 svn revert wc/A/g This does require that you identify the problem file. -- Philip IMPORTANT NOTE: The information in this e-mail (and any attachments) is confidential. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient, please notify the sender immediately or telephone: +353 (0)1 6204700. We cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. If you suspect that the message may have been intercepted or amended, please call the sender.
RE: svn: E235000: error when performin a svn switch with SVN 1.7.4
HI Philip, Ive recreated it quite simply. How long will it take for a new drop of SVN with a fix for this to be released? Thx Derek # Current Checkout (link to a file) (245975) [derek.wallace@dublogon1 test]$ l svn_links total 16 drwxrwxr-x 3 derek.wallace Intune Staff 1024 Apr 18 12:44 . drwxrwxr-x 17 derek.wallace Intune Staff 2048 Apr 18 12:48 .. lrwxrwxrwx 1 derek.wallace Intune Staff 18 Apr 18 12:44 derek1.txt -> folder1/derek1.txt drwxrwxr-x 2 derek.wallace Intune Staff 80 Apr 18 12:26 folder1 [derek.wallace@dublogon1 test]$ svn info svn_links Path: svn_links Working Copy Root Path: /scratch-disk4/derek.wallace/IVX8000_trunk_FPGA URL: svn://dubsvn1/inx8000-cr1-fpga/ivx8000/trunk/trunk/test/svn_links Repository Root: svn://dubsvn1/inx8000-cr1-fpga Repository UUID: baad5aac-ed56-0410-b601-f48d8304e233 Revision: 245975 Node Kind: directory Schedule: normal Last Changed Author: derek.wallace Last Changed Rev: 245975 Last Changed Date: 2012-04-18 12:45:09 +0100 (Wed, 18 Apr 2012) # switch to a revisions (245973) that doesn't have a link, but has the file name [derek.wallace@dublogon1 test]$ svn switch svn://dubsvn1/inx8000-cr1-fpga/ivx8000/trunk/trunk/test/svn_links@245973 svn_links svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line 1583: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) Aborted (core dumped) # remove folder [derek.wallace@dublogon1 test]$ rm -rf svn_links # checkout [derek.wallace@dublogon1 test]$ svn up svn_links -r245973 Updating 'svn_links': Restored 'svn_links' Restored 'svn_links/derek1.txt' Restored 'svn_links/folder1' Restored 'svn_links/folder1/derek1.txt' Dsvn_links/derek1.txt Asvn_links/derek1.txt Updated to revision 245973. [derek.wallace@dublogon1 test]$ svn switch svn://dubsvn1/inx8000-cr1-fpga/ivx8000/trunk/trunk/test/svn_links@245975 svn_links svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line 1583: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) Aborted (core dumped) [derek.wallace@dublogon1 test]$ svn cleanup [derek.wallace@dublogon1 test]$ svn switch svn://dubsvn1/inx8000-cr1-fpga/ivx8000/trunk/trunk/test/svn_links@245973 svn_links At revision 245973. [derek.wallace@dublogon1 test]$ svn switch svn://dubsvn1/inx8000-cr1-fpga/ivx8000/trunk/trunk/test/svn_links@245975 svn_links svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line 1583: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) Aborted (core dumped) -Original Message- From: Derek Wallace Sent: 18 April 2012 12:44 To: Philip Martin Cc: users@subversion.apache.org; Niamh Scott; Derek Wallace; Dennis Lyness Subject: RE: svn: E235000: error when performin a svn switch with SVN 1.7.4 Hi Philip, Thanks for looking into this. Im trying to create a simple recipe to illustrate the problem. While I was creating the recipe this happened. # Currently I have derek1.txt as a file [derek.wallace@dublogon1 svn_links]$ l total 16 drwxrwxr-x 3 derek.wallace Intune Staff 1024 Apr 18 12:26 . drwxrwxr-x 17 derek.wallace Intune Staff 2048 Apr 16 11:57 .. -rw-rw-r-- 1 derek.wallace Intune Staff0 Apr 16 12:17 derek1.txt drwxrwxr-x 2 derek.wallace Intune Staff 80 Apr 18 12:26 folder1 # Delete the file [derek.wallace@dublogon1 svn_links]$ rm derek1.txt # Create Link with the same name [derek.wallace@dublogon1 svn_links]$ ln -s folder1/derek1.txt [derek.wallace@dublogon1 svn_links]$ l total 16 drwxrwxr-x 3 derek.wallace Intune Staff 1024 Apr 18 12:27 . drwxrwxr-x 17 derek.wallace Intune Staff 2048 Apr 16 11:57 .. lrwxrwxrwx 1 derek.wallace Intune Staff 18 Apr 18 12:27 derek1.txt -> folder1/derek1.txt drwxrwxr-x 2 derek.wallace Intune Staff 80 Apr 18 12:26 folder1 # Tran and commit. [derek.wallace@dublogon1 svn_links]$ svn ci -m "" svn: E145001: Commit failed (details follow): svn: E145001: Entry '/scratch-disk4/derek.wallace/IVX8000_trunk_FPGA/test/svn_links/derek1.txt' has unexpectedly changed special status [derek.wallace@dublogon1 svn_links]$ Ill continue to try and create the receipe. Thx Derek -Original Message- From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of Philip Martin Sent: 18 April 2012 09:24 To: Derek Wallace Cc: users@subversion.apache.org Subject: Re: svn: E235000: error when performin a svn switch with SVN 1.7.4 Philip Martin writes: > Philip Martin writes: > >> Please describe the changes made by the switch. Running >> >> svn diff --summarive URL_OF_WC URL_OF_SWITCH_TARGET >> >> may help. > > I think I may have identified it: > > svnadmin create repo > svn import repo/format -mm file://`pwd`/repo/A/f svn co > file://`pwd`/repo wc ln -s f wc/A/g svn add wc/A/g svn ci -mm wc
Re: Subversion mangling passwords to apache over https
"Cooke, Mark" writes: > Quick Summary: subversion (both TortoiseSVN and the command-line > client provided by TSVN) is changing certain characters whilst using > Basic Authentication (over https, from Windows XP) to apache 2.2 (on > Windows Server 2003). So far I have confirmed this for the UK > keyboard `£` (SHIFT-3): > >> When using a browser, I get the following for -1 >> through -0 on my UK keyboard (bounded by '[]'): >> >> 2012-04-17 16:03:09.734000 : svntest [!"£$%^&*()] >> >> ...but when I use the svn command line client I log instead: >> >> 2012-04-17 16:01:52.124000 : svntest [!"œ$%^&*()] >> >> Note that the `£` is now different. I think that this explains >> the `Password Mismatch` error? > > Philip Martin has already responded (thanks!) with: > >> Non-ascii passwords are a problem for HTTP because there is >> no standard for encoding the password before constructing the >> digest, nor is there a standard for the client to tell the >> server which encoding it used. Because there is no standard >> clients tend to do different things. Some clients will >> convert the password to UTF-8, some clients will convert to >> some other encoding, and some clients will leave it in whatever >> encoding the user entered. > > ...which helps to explain the problem (except we are using `basic` > plain text, not digest) but I cannot believe that we are the only > subversion users with this problem, what about other users with > non-latin character sets (Russia, Israel etc)? You have exactly the same problem with basic auth, there is no standard for encoding non-ASCII passwords. It's generally possible to adjust the password storage on the server so that any given client works, but it not possible to get all clients to work. Suppose I have a password consisting of a single '£' character. In ISO-8859-1 that is the single byte 0xA3, in UTF-8 that is two bytes 0xC2 0xA3. If I combine that with a username pm2 the the basic auth token is given by $ echo -n pm2:£ | base64 In ISO-8859-1 this gives 'cG0yOqM=' while in UTF-8 it gives 'cG0yOsKj'. When you store the password on the server in an htpasswd file you choose to store either the literal passowrd or a password hash. If you store the password literally as the line pm2:£ you have to choose how to store the password. If you use the one-byte form the 'cG0yOqM=' auth token will work, if you use the two-byte form the 'cG0yOsKj' auth token will work. If you use some other form, such as UTF-16, then neither of those tokens will work. It's more usual to store password hashes but the same problem occurs. If you store the password hash, using a salt AA, it's typically $ mkpassword £ AA in IS0-8859-1 this leads to the line pm2:AACiVWnPwZTeE and the 'cG0yOqM=' token will work. In UTF-8 it leads to the line pm2:AAzOZFufPfaOQ and the 'cG0yOsKj' token will work. A client like curl does no password encoding conversion, so the command $ curl http://... -u pm2:£ will send the token 'cG0yOqM=' when running in an IS0-8859-1 environment and the token 'cG0yOsKj' when running in UTF-8. Only one of these will work depending on how the htpasswd file is set up. A client like the svn converts passwords from the command line or keyboard to UTF-8 so the command $ svn cat http://... --username pm --password £ will always send the 'cG0yOsKj' auth token. This will work if the htpasswd has been setup for UTF-8 and it will work whatever environment is being used by the client, but will fail if the htpasswd file has not been setup for UTF-8 Other clients such as TSVN or web browsers may behave like curl, or they may behave like svn, or they may do something else. By adjusting the setup on the server you can generally get any given client to work in any given encoding, but there is no way to get all clients to work in all encodings. It gets even more complicated when you consider password caching: the passwords that Subversion stores are in UTF-8 and Subversion assumes that they are still UTF-8 when retrieved. However if the password store is shared with other clients, say a web browser, then those other clients may have stored non-UTF-8 passwords and this will cause Subversion to send non-UTF-8 auth tokens. That works if the server is setup so that non-UTF-8 tokens work. -- Philip
Re: svn: E235000: error when performin a svn switch with SVN 1.7.4
Derek Wallace writes: > How long will it take for a new drop of SVN with a fix for this to be > released? See http://subversion.tigris.org/issues/show_bug.cgi?id=4160 -- Philip
Re: AW: Info about SVN
Andre seems to be going through a checklist of specific features, not necessarily part of any one tool like Subversion. It's like looking on Craig's list for houses with swimming pools, helipads, and low mortgage rates. It's conceivable but very unlikely to find all those features. Andre, I urge you to talk with the commercial vendors like Wandisco about enterprise suites. What features they lack, they may be able to design and sell you.
Re: default ignores
On Apr 17, 2012, at 13:34, Les Mikesell wrote: > 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. Well, yes you can un-add something: Add: $ svn add foo A foo Un-add: $ svn revert foo Reverted 'foo' There are several places where this information can be found by Googling "svn unadd". But if you commit the addition: $ svn add foo A foo $ svn ci foo -m x Adding foo Transmitting file data . Committed revision 1. Then you're right you can't un-commit that; you'd have to reverse merge, and there'd be a permanent record of it in the repository.
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
