SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
Hello all, I have searched for this issue in several places, but none of the feature requesters presented a scenario like mine, and the overall conclusion was that the svn:ignore property was sufficient. However, I stand by the opinion that a local .svnignore file is also necessary (or some kind of _unversioned_ svn:localignore property). So, I'd like to see some additional opinions on the matter. Details follow. I have a build system that allows me to compile C/C++ code from a single repository for a number of different platforms, including several flavors of 32- and 64-bit Windows, Linux and MAC. During setup and compilation, the system generates several local files, which are different depending on the selected target platform, the selected in-development projects, and some other local configurations. These files are unversioned and should be ignored by the versioning tool. Until some time ago, I used CVS as my versioning tool, and the .cvsignore file worked perfectly. The build system knows what files will be generated for the current configuration, so it just created the .cvsignore file and filled it with the names of those files. Now, I have migrated my repository to SVN, and I am having trouble with the fact that the svn:ignore property is versioned. Since the list of ignored files varies with the local configuration, it is usually different for each developer in my team, and the source-code folders are always marked by SVN as modified, which is kind of inconvenient. The only solution I could think of (to be able to keep a somewhat stable svn:ignore property) would be to populate the svn:ignore property with every file that could ever be automatically generated by the build system when operating in each and every local configuration scenario. Even then, however, there is still some unnecessary hassle: - For the property to be automatically updated, the build system would have to simulate every possible configuration (lots of possibilities) to update the svn:ignore property, which is a lot more work that working only with the single, currently selected configuration. - The system could get the current svn:ignore property and only add new items to it based on the currently selected configuration, but this may result in unnecessarily bloated svn:ignore properties over time, since no-longer-generated files would never be removed from the list. - If the property is to be managed manually, then the developers must remember to always update the svn:ignore property themselves every time a new file is automatically generated or an old file ceases to be generated. This is error-prone and requires every developer to know about the internals of the build system. The second option above is the strongest solution in my opinion, but it is still more complex than a simple .svnignore file (or an extra unversioned ignore property), and yet results in a not-as-good behavior. So, I would like to know if anyone has a better idea, and/or if anyone agrees that a local .svnignore file (or an extra unversioned svn:ignore property) has a good use after all. Thanks for the attention, Vitor
RE: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> I have searched for this issue in several places, but none of the feature > requesters presented a scenario like mine, and the overall conclusion was that > the svn:ignore property was sufficient. However, I stand by the opinion that a > local .svnignore file is also necessary (or some kind of _unversioned_ > svn:localignore property). So, I'd like to see some additional opinions on the > matter. Details follow. > > I have a build system that allows me to compile C/C++ code from a single > repository for a number of different platforms, including several flavors of > 32- > and 64-bit Windows, Linux and MAC. During setup and compilation, the system > generates several local files, which are different depending on the selected > target platform, the selected in-development projects, and some other local > configurations. These files are unversioned and should be ignored by the > versioning tool. > > Until some time ago, I used CVS as my versioning tool, and the .cvsignore > file > worked perfectly. The build system knows what files will be generated for the > current configuration, so it just created the .cvsignore file and filled it > with the > names of those files. Now, I have migrated my repository to SVN, and I am > having trouble with the fact that the svn:ignore property is versioned. Since > the > list of ignored files varies with the local configuration, it is usually > different for > each developer in my team, and the source-code folders are always marked by > SVN as modified, which is kind of inconvenient. > The only solution I could think of (to be able to keep a somewhat stable > svn:ignore property) would be to populate the svn:ignore property with every > file that could ever be automatically generated by the build system when > operating in each and every local configuration scenario. Even then, however, > there is still some unnecessary hassle: > > - For the property to be automatically updated, the build system would have to > simulate every possible configuration (lots of possibilities) to update the > svn:ignore property, which is a lot more work that working only with the > single, > currently selected configuration. > - The system could get the current svn:ignore property and only add new items > to it based on the currently selected configuration, but this may result in > unnecessarily bloated svn:ignore properties over time, since no-longer- > generated files would never be removed from the list. > - If the property is to be managed manually, then the developers must > remember to always update the svn:ignore property themselves every time a > new file is automatically generated or an old file ceases to be generated. > This > is error-prone and requires every developer to know about the internals of the > build system. > > The second option above is the strongest solution in my opinion, but it > is still > more complex than a simple .svnignore file (or an extra unversioned ignore > property), and yet results in a not-as-good behavior. So, I would like to > know if > anyone has a better idea, and/or if anyone agrees that a local .svnignore file > (or an extra unversioned svn:ignore property) has a good use after all. > > Thanks for the attention, > Vitor A couple of thoughts. Each developer for their specific platform could have a global ignores files that ignores the files that are specific to their platform/tool. You can generate a global ignore file since it is just a text file and place it in the correct location. Configure your build system and tools to place all build artifacts into an ignored work folder and copy files that are versioned into their correct locations. If the build is doing the "add" then it could create the svn:ignore property, do the "add" and then remove the property. Just some other possiblitites. BOb
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
Guten Tag Vitor Barata, am Montag, 29. Oktober 2012 um 16:56 schrieben Sie: > So, I would like to know if anyone has a better idea, and/or > if anyone agrees that a local .svnignore file (or an extra unversioned > svn:ignore property) has a good use after all. I don't think I did fully understand the interaction between your build system and your devs, as normally build systems like Jenkins, Hudson etc. run on a separate server fully automated and per default just don't commit anything, therefore it's very unimportant if the working copy they are working on is flagged as changed in any way or not. So your build system is used on the devs machines and works on the same working copy as your devs work on that you get a problem with svn status? Which subversion clients do you use? If I read Windows I think of TortoiseSVN, which can be configured to exclude special folders as being marked as modified. Besides that, there's a global-ignores property for clients, too: [miscellany] ### Set global-ignores to a set of whitespace-delimited globs ### which Subversion will ignore in its 'status' output, and ### while importing or adding files and directories. ### '*' matches leading dots, e.g. '*.rej' matches '.foo.rej'. # global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo # *.rej *~ #*# .#* .*.swp .DS_Store Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
SVN Tag / Branch question
Hello, We did our first release in SVN today. I used the copy command (shown below) to copy from /trunk to /tag. Since not everything in /trunk was needed for this release, I had to specify the directories which were needed. Q1. Is this the normal/correct way of doing things? For the new release, just the Docs, MKVIE and Screens dirs. were needed. The others were not. Our repo structure is as follows: C>svn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX Control/ Docs/ MKVIE/ Screens/ sem_modbus/ Q2. Are we better off using release branches instead of copying to /tags? Q3. Sometime down the line, if I had to re-create a view of "Release 1.6", do I just base my workspace on what's in /tags/release-1.6? Or is there another/better way of re-creating a prior release? Q4. I was also expecting /tags to contain just the new files for Release 1.6. However, that wouldn't be case, right? I have a feeling I am confusing myself over nothing. C:\>svn copy -m "Release 1.6" https://X.X.com/svn/muxbopcs_svn/trunk/MUX/MKVIEW/ https://X.X.com/svn/muxbopcs_svn/tags/release-1.6/
Editing svn:log property on file
Hi, I'm trying to setup an subversion replication between two servers (both running version 1.6.11). When I try to replicate the data, I get the following error in the logs: Cannot accept 'svn:log' property because it is not encoded in UTF-8 [500, #125005] I've figured out which property it is, but the problem is that it is the property on the file that was modified itself, rather than on the revision. This is the "svn:log" property on the revision, which is not causing the problem (I've modified it to remove and special characters and ran it through xxd): $ svn propget --revprop -r 6107 --strict svn:log " http://subversion/src/Flow/"; When printing a form through the full task list the clients NHI number has B and B beside it for cds. This is the "svn:log" property on the actual file which was modified, which I believe is causing the issue (see the formatting around "client"): $ svn proplist -v servicePack_merge.c5x Properties on 'servicePack_merge.c5x': svn:log When printing a form through the full task list the client?\146s NHI number has and beside it (for cds). svn:author Xing svn:date 2004-04-28T01:31:40.00Z I've tried modifying this property on the file, as opposed to the revision, with not much luck. The following command lets me modify the revision "svn:log" as opposed to the one associated directly with the file: svn propedit -r 6107 --revprop svn:log " http://subversion/src/Flow/trunk/servicePack_merge.c5x"; I've also tried this command to edit the property: svn propedit -r 6107 svn:log http://subversion/src/Flow/trunk/servicePack_merge.c5x svn: Try 'svn help' for more info svn: Cannot specify revision for editing versioned property 'svn:log' But still no luck. Can anyone tell me how to modify the "svn:log" property on the file itself, as opposed to the revision property? Has anyone seen this issue before? Thank you -- Srdan Dukic
Re: Editing svn:log property on file
Srdan Dukic wrote on Tue, Oct 30, 2012 at 15:20:24 +1300: > But still no luck. Can anyone tell me how to modify the "svn:log" property > on the file itself, as opposed to the revision property? Has anyone seen > this issue before? > You need to use some tool that modifies history. (Which tool? Look for svndumptool/2/3, but I don't follow closely the latest recommendations for this task.) Changing a property on a node (file or directory) is not fundamentally different from changing the textual contents of a file. Maybe we should relax the validation to not validate svn:log when it is a node property (as opposed to a revision property). If anyone wants to pursue this, contact dev@ please. > Thank you > -- > Srdan Dukic
Re: Editing svn:log property on file
Srdan Dukic wrote on Tue, Oct 30, 2012 at 15:20:24 +1300: > Hi, > > I'm trying to setup an subversion replication between two servers (both > running version 1.6.11). When I try to replicate the data, I get the > following error in the logs: ... > But still no luck. Can anyone tell me how to modify the "svn:log" property > on the file itself, as opposed to the revision property? Has anyone seen > this issue before? By the way, there is another solution: you try doing a dump/load of the revision that sets the bogus property value. (Dump from the master, load on the slave.) (You could generate the dump with svnrdump -r N or with 'svnadmin dump -r N --deltas --incremental'.) Pass --bypass-prop-validation to 'svnadmin load'. [ Note for the archives: the sense of the --bypass-prop-validation boolean (presence/absence) flag was reversed, for revision properties only, up to 1.7.7 (inclusive). See r1237779. ]
Re: Editing svn:log property on file
Thanks for that. Using svnadmin "dump" and then "load" worked. I didn't even have to pass the "--bypass-prop-validation" option to the load command, as it seems the non-UTF8 symbols were converted to a "?" by the dump command. -- Srdan Dukic On 30 October 2012 15:57, Daniel Shahaf wrote: > Srdan Dukic wrote on Tue, Oct 30, 2012 at 15:20:24 +1300: > > Hi, > > > > I'm trying to setup an subversion replication between two servers (both > > running version 1.6.11). When I try to replicate the data, I get the > > following error in the logs: > ... > > But still no luck. Can anyone tell me how to modify the "svn:log" > property > > on the file itself, as opposed to the revision property? Has anyone seen > > this issue before? > > By the way, there is another solution: you try doing a dump/load of the > revision that sets the bogus property value. (Dump from the master, > load on the slave.) (You could generate the dump with svnrdump -r N or > with 'svnadmin dump -r N --deltas --incremental'.) Pass > --bypass-prop-validation to 'svnadmin load'. > > [ Note for the archives: the sense of the --bypass-prop-validation > boolean (presence/absence) flag was reversed, for revision properties > only, up to 1.7.7 (inclusive). See r1237779. ] >
Re: Editing svn:log property on file
Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > Thanks for that. Using svnadmin "dump" and then "load" worked. > > I didn't even have to pass the "--bypass-prop-validation" option to the > load command, as it seems the non-UTF8 symbols were converted to a "?" by > the dump command. How are you checking that? The 'dump' command doesn't know about UTF-8 requirements for property values; it should preserve arbitrary byte sequences. (In other words, the output of 'propget --strict | xxd' should be identical between master and slave.)
Re: Editing svn:log property on file
Checked it by examining the contents of the dump file (cat [dumpfile]). Where I expected to see: client?\146s I instead got: client?s Then, after copying it over to the slave and running "load", without the "--bypass-prop-validation" flag, the dump is loaded without any errors complaining about the encoding of the properties. -- Srdan Dukic On 30 October 2012 16:51, Daniel Shahaf wrote: > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > I didn't even have to pass the "--bypass-prop-validation" option to the > > load command, as it seems the non-UTF8 symbols were converted to a "?" by > > the dump command. > > How are you checking that? The 'dump' command doesn't know about UTF-8 > requirements for property values; it should preserve arbitrary byte > sequences. (In other words, the output of 'propget --strict | xxd' > should be identical between master and slave.) >
Re: Editing svn:log property on file
Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > Checked it by examining the contents of the dump file (cat [dumpfile]). > Where I expected to see: > > client?\146s > Wrong expectation, dump files never include this syntax. > I instead got: > > client?s > This doesn't say whether it was a literal question mark (0x3F) in the file or not. > Then, after copying it over to the slave and running "load", without the > "--bypass-prop-validation" flag, the dump is loaded without any errors > complaining about the encoding of the properties. > > -- > Srdan Dukic > > On 30 October 2012 16:51, Daniel Shahaf wrote: > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > I didn't even have to pass the "--bypass-prop-validation" option to the > > > load command, as it seems the non-UTF8 symbols were converted to a "?" by > > > the dump command. > > > > How are you checking that? The 'dump' command doesn't know about UTF-8 > > requirements for property values; it should preserve arbitrary byte > > sequences. (In other words, the output of 'propget --strict | xxd' > > should be identical between master and slave.) > >
Re: Editing svn:log property on file
Hmmm... yes indeed. This does seem to be the case, as the same developer committed the same file, with the same log message in another location, and this time the dump/load is not working. Even though the load doesn't throw any errors, when continuing with the svnsync after loading, it starts complaining about UTF-8 again and won't load the version. -- Srdan Dukic On 30 October 2012 17:04, Daniel Shahaf wrote: > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > Checked it by examining the contents of the dump file (cat [dumpfile]). > > Where I expected to see: > > > > client?\146s > > > > Wrong expectation, dump files never include this syntax. > > > I instead got: > > > > client?s > > > > This doesn't say whether it was a literal question mark (0x3F) in the > file or not. > > > > Then, after copying it over to the slave and running "load", without the > > "--bypass-prop-validation" flag, the dump is loaded without any errors > > complaining about the encoding of the properties. > > > > -- > > Srdan Dukic > > > > On 30 October 2012 16:51, Daniel Shahaf wrote: > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option to > the > > > > load command, as it seems the non-UTF8 symbols were converted to a > "?" by > > > > the dump command. > > > > > > How are you checking that? The 'dump' command doesn't know about UTF-8 > > > requirements for property values; it should preserve arbitrary byte > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > should be identical between master and slave.) > > > >
Re: Editing svn:log property on file
IIRC svnsync would only complain about revisions add or modify an svn:log property --- other changes to files having that property (even with a bad value) should sync errorlessly. See validate_revision() in subversion/libsvn_repos/fs-wrap.c Anyway. I suggest you figure out a way to exclude "svn:log" node properties from the sync. If there is an easier way to do that than to patch change_file_prop() in subversion/svnsync/, I'm sure someone will suggest it. Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:15:18 +1300: > Hmmm... yes indeed. This does seem to be the case, as the same developer > committed the same file, with the same log message in another location, and > this time the dump/load is not working. > > Even though the load doesn't throw any errors, when continuing with the > svnsync after loading, it starts complaining about UTF-8 again and won't > load the version. > > -- > Srdan Dukic > > On 30 October 2012 17:04, Daniel Shahaf wrote: > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > > Checked it by examining the contents of the dump file (cat [dumpfile]). > > > Where I expected to see: > > > > > > client?\146s > > > > > > > Wrong expectation, dump files never include this syntax. > > > > > I instead got: > > > > > > client?s > > > > > > > This doesn't say whether it was a literal question mark (0x3F) in the > > file or not. > > > > > > > Then, after copying it over to the slave and running "load", without the > > > "--bypass-prop-validation" flag, the dump is loaded without any errors > > > complaining about the encoding of the properties. > > > > > > -- > > > Srdan Dukic > > > > > > On 30 October 2012 16:51, Daniel Shahaf wrote: > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option to > > the > > > > > load command, as it seems the non-UTF8 symbols were converted to a > > "?" by > > > > > the dump command. > > > > > > > > How are you checking that? The 'dump' command doesn't know about UTF-8 > > > > requirements for property values; it should preserve arbitrary byte > > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > > should be identical between master and slave.) > > > > > >
Re: Editing svn:log property on file
Yes, it was the "svn:log" property on the revision (as opposed to the node) which was causing the issue. Was able to modify it with the "propset" command and it has allowed svnsync to continue the sync. So, the file to be patched is: http://svn.apache.org/repos/asf/subversion/trunk/subversion/svnsync/sync.c Is it the section that's commented as "Normalize svn:* properties as necessary." that the error's being thrown? -- Srdan Dukic On 30 October 2012 17:21, Daniel Shahaf wrote: > IIRC svnsync would only complain about revisions add or modify an > svn:log property --- other changes to files having that property (even > with a bad value) should sync errorlessly. See validate_revision() in > subversion/libsvn_repos/fs-wrap.c > > Anyway. I suggest you figure out a way to exclude "svn:log" node > properties from the sync. If there is an easier way to do that than to > patch change_file_prop() in subversion/svnsync/, I'm sure someone will > suggest it. > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:15:18 +1300: > > Hmmm... yes indeed. This does seem to be the case, as the same developer > > committed the same file, with the same log message in another location, > and > > this time the dump/load is not working. > > > > Even though the load doesn't throw any errors, when continuing with the > > svnsync after loading, it starts complaining about UTF-8 again and won't > > load the version. > > > > -- > > Srdan Dukic > > > > On 30 October 2012 17:04, Daniel Shahaf wrote: > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > > > Checked it by examining the contents of the dump file (cat > [dumpfile]). > > > > Where I expected to see: > > > > > > > > client?\146s > > > > > > > > > > Wrong expectation, dump files never include this syntax. > > > > > > > I instead got: > > > > > > > > client?s > > > > > > > > > > This doesn't say whether it was a literal question mark (0x3F) in the > > > file or not. > > > > > > > > > > Then, after copying it over to the slave and running "load", without > the > > > > "--bypass-prop-validation" flag, the dump is loaded without any > errors > > > > complaining about the encoding of the properties. > > > > > > > > -- > > > > Srdan Dukic > > > > > > > > On 30 October 2012 16:51, Daniel Shahaf > wrote: > > > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option > to > > > the > > > > > > load command, as it seems the non-UTF8 symbols were converted to > a > > > "?" by > > > > > > the dump command. > > > > > > > > > > How are you checking that? The 'dump' command doesn't know about > UTF-8 > > > > > requirements for property values; it should preserve arbitrary byte > > > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > > > should be identical between master and slave.) > > > > > > > > >
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> I don't think I did fully understand the interaction between your > build system and your devs, as normally build systems like Jenkins, > Hudson etc. run on a separate server fully automated and per default > just don't commit anything, therefore it's very unimportant if the > working copy they are working on is flagged as changed in any way or > not. So your build system is used on the devs machines and works on the > same working copy as your devs work on that you get a problem with svn > status? Maybe I called our system the wrong name. It is a homemade system, and here are some of the things that it does: 1) Each project is specified by a custom configuration file, which lists the source files to be compiled using different tools and sets up project-specific options. These configuration files are versioned and may contain conditional options based on target platform and other global options. 2) A developer chooses from a list which projects he wishes to work on, and edits a configuration file to indicate the platform he wishes to compile to, build flags and several other options. These local options are specified by locally modifying a versioned template file. The modified file is marked as ignored, no problems here. 3) The system checks out or updates all relevant code from the repository, including the selected projects and, depending on the local options, other projects on which they depend, or that depend on them. This is done with svn sparse directories, no problems either. 4) The system automatically generates platform- and option-dependent files, such as makefiles on Linux and Visual Studio project and solution files on Windows. These are marked as ignored. 5) Before compilation, several tools produce some automatically-generated source code, such as bindings between two programming languages. These files can be different depending on the target platform and other options, and there can be quite a lot of them. They should also be marked as ignored, but there is no naming pattern or specific location for them, which makes it hard to use global ignore patterns. Since the automatically-generated files are often #included in other non-automatic source files, the developer is free to choose the location and naming which are best for him. The names and locations are specified in the project configuration files. 6) After compilation, the system copies some files around, such as exported library headers and DLL dependencies of the generated executables. 7) The system also automatically generates installation scripts and executables for the end-users. Number 5 above is probably the most problematic case. We _could_ try to impose a specific location and naming pattern for those files, but this could affect headers used by client developers as well, so we would rather avoid that if possible. > Which subversion clients do you use? TortoiseSVN in Windows, just the command line in Unix.
Issue while setting up subversion repository on Solaris 5.10
Hi Team, Iam facing an issue while setting up subversion repository on Solaris 5.10 PFB the steps followed. 1. Execute ‘svnadmin create /data/installs/repo’ Give 777 permissions to the files and folders in /data/installs/repo 2. Go to the folder /data/installs/repo/conf Modify svnserve.conf file Uncomment anon-access = read, auth-access = write, password-db = passwd Modify passwd file Add sapna = sapna as credentials. 3. Execute ‘svnserve -d -r /data/installs/repo’ 4. Execute ‘svn mkdir svn://10.237.205.46/project’ It opens up vi editor. Save and continue. It prompts for root password. Provide the password. It prompts for username and password. Provide sapna/sapna If it prompts for ‘Store password unencrypted?(yes/no)’, provide yes We are getting the error ‘svn:Network connection closed unexpectedly’ after the 4th command. Please help me to resolve this issue. Regards, Sapna P B
