svnignore?
What is the equivalent of the CVS .cvsignore file? I have a lot of files that I don't want to get into the repository because they are only temporary files created by the compiler every time I do almost anything in the IDE. These are ignored when we use CVS by the use of a global cvsignore setting plus .cvsignore files in projects that need some more files ignored. My main cvsignore file has something like 40-50 entries.. I tried to study the svnbook on this matter but the closest I get is to use: svn propedit svn:ignore But this seems to be an exercise to be done on directory levels and my IDE creates a lot of directories that are not versioned to begin with... Is there no way to make a global setting on the client side such that the known files types will be ignored from svn? If it matters I use the SmartSvn program as a user interface on my development PC. It was recommended for users wanting a GUI interface like we had for CVS. -- Bo Berglund Developer in Sweden
Re: svnignore?
On 12/29/2017 7:57 AM, Bo Berglund wrote: What is the equivalent of the CVS .cvsignore file? I have a lot of files that I don't want to get into the repository because they are only temporary files created by the compiler every time I do almost anything in the IDE. These are ignored when we use CVS by the use of a global cvsignore setting plus .cvsignore files in projects that need some more files ignored. My main cvsignore file has something like 40-50 entries.. I tried to study the svnbook on this matter but the closest I get is to use: svn propedit svn:ignore But this seems to be an exercise to be done on directory levels and my IDE creates a lot of directories that are not versioned to begin with... Is there no way to make a global setting on the client side such that the known files types will be ignored from svn? If it matters I use the SmartSvn program as a user interface on my development PC. It was recommended for users wanting a GUI interface like we had for CVS. Tell Subversion to ignore temporary files in a working copy by editing the "global-ignores" line in the file "config". On Windows systems this is in "AppData\Roaming\Subversion" within the user's home directory; on Linux systems this is in ".subversion" within the user's home directory. These are global per user, not per working copy. For example, my "global-ignores" line for Windows is: global-ignores = *.obj *.lib *.ciz *.map *.exe *.bak *.pdb *.ilk *.idb Note that these directories are not present for a given user until that person has run some Subversion command on the machine. "svn --version" should be enough. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA EDA Software Developer, Expert Witness www.chapman-consulting-sj.com
Re: svnignore?
On Dec 29, 2017, at 11:24, David Chapman wrote: > On 12/29/2017 7:57 AM, Bo Berglund wrote: >> What is the equivalent of the CVS .cvsignore file? >> >> I have a lot of files that I don't want to get into the repository >> because they are only temporary files created by the compiler every >> time I do almost anything in the IDE. These are ignored when we use >> CVS by the use of a global cvsignore setting plus .cvsignore files in >> projects that need some more files ignored. >> My main cvsignore file has something like 40-50 entries.. >> >> I tried to study the svnbook on this matter but the closest I get is >> to use: >> svn propedit svn:ignore >> But this seems to be an exercise to be done on directory levels and my >> IDE creates a lot of directories that are not versioned to begin >> with... >> Is there no way to make a global setting on the client side such that >> the known files types will be ignored from svn? >> >> If it matters I use the SmartSvn program as a user interface on my >> development PC. It was recommended for users wanting a GUI interface >> like we had for CVS. >> >> > > Tell Subversion to ignore temporary files in a working copy by editing the > "global-ignores" line in the file "config". On Windows systems this is in > "AppData\Roaming\Subversion" within the user's home directory; on Linux > systems this is in ".subversion" within the user's home directory. These are > global per user, not per working copy. > > For example, my "global-ignores" line for Windows is: > > global-ignores = *.obj *.lib *.ciz *.map *.exe *.bak *.pdb *.ilk *.idb > > Note that these directories are not present for a given user until that > person has run some Subversion command on the machine. "svn --version" > should be enough. As of Subversion 1.8, you can configure svn:global-ignores in the repository as well. http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.ignore.html "Subversion 1.8 provides a more powerful version of the svn:ignore property, the svn:global-ignores property. Like the svn:ignore property,svn:global-ignores can only be set on a directory and contains file patterns Subversion uses to determine ignorable objects.[21] These ignore patterns are also appended to any patterns defined in the global-ignores runtime configuration option together with any svn:ignore defined patterns. Unlike svn:ignore however, the svn:global-ignores property is inheritable [22] and applies to all paths under the directory on which the property is set, not just the immediate children of the directory."
Re: svnignore?
On Fri, 29 Dec 2017 09:24:10 -0800, David Chapman wrote: >On 12/29/2017 7:57 AM, Bo Berglund wrote: >> Is there no way to make a global setting on the client side such that >> the known files types will be ignored from svn? >> > >Tell Subversion to ignore temporary files in a working copy by editing >the "global-ignores" line in the file "config". On Windows systems this >is in "AppData\Roaming\Subversion" within the user's home directory; on >Linux systems this is in ".subversion" within the user's home >directory. These are global per user, not per working copy. > >For example, my "global-ignores" line for Windows is: > >global-ignores = *.obj *.lib *.ciz *.map *.exe *.bak *.pdb *.ilk *.idb > OK, I found it in the location you specified! But if I add the content of my cvsignore file to the config file as a whitespace separated list on one line that line becomes VERY log (over 600 chars). Can I put the info in separate lines? And by the way the config file is organized in sections so one has to enter the data in the [miscellany] section. -- Bo Berglund Developer in Sweden
Re: svnignore?
On Fri, 29 Dec 2017 19:05:06 +0100, Bo Berglund wrote: >On Fri, 29 Dec 2017 09:24:10 -0800, David Chapman >wrote: >But if I add the content of my cvsignore file to the config file as a >whitespace separated list on one line that line becomes VERY log (over >600 chars). >Can I put the info in separate lines? > It turns out that enabling this option by removing the # character makes SmartSvn barf when I want to check out a project! So it is necessary also to remove all whitespace *before* the global-ignores text. After this whitespace is permissible. This is how my file looks now for ignores (the ignore globs are all on one line, the newsreader has added the line breaks): [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 *.a *.aps *.bak *.BAK *.bpt *.bro *.bsc *.cdb *.cfg *.cgl *.class *.compiled *.clw *.db *.dbg *.dcu *.DCU *.ddp *.dsk *.dti *.err *.exp *.gid *.gz*.identcache *.ilk *.jar *.lnk *.local *.log *.lps *.lrt *.mod *.MOD *.ncb *.NCB *.ocx *.OPT *.opt *.pch *.pjt *.plg *.PLG *.pdb *.PDB *.ppu *.o *.obj *.OBJ *.or *.rsj *.rst *.sbr *.scc *.SID *.sln *.tar *.tds *.tlh*.tli *.trg *.vbw *.zip __history bak *.~* .#* I guess it is not valid to split the list on several lines in they config file? -- Bo Berglund Developer in Sweden
Re: svnignore?
On 12/29/2017 10:55 AM, Bo Berglund wrote: On Fri, 29 Dec 2017 19:05:06 +0100, Bo Berglund wrote: On Fri, 29 Dec 2017 09:24:10 -0800, David Chapman wrote: But if I add the content of my cvsignore file to the config file as a whitespace separated list on one line that line becomes VERY log (over 600 chars). Can I put the info in separate lines? It turns out that enabling this option by removing the # character makes SmartSvn barf when I want to check out a project! So it is necessary also to remove all whitespace *before* the global-ignores text. After this whitespace is permissible. This is how my file looks now for ignores (the ignore globs are all on one line, the newsreader has added the line breaks): [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 *.a *.aps *.bak *.BAK *.bpt *.bro *.bsc *.cdb *.cfg *.cgl *.class *.compiled *.clw *.db *.dbg *.dcu *.DCU *.ddp *.dsk *.dti *.err *.exp *.gid *.gz*.identcache *.ilk *.jar *.lnk *.local *.log *.lps *.lrt *.mod *.MOD *.ncb *.NCB *.ocx *.OPT *.opt *.pch *.pjt *.plg *.PLG *.pdb *.PDB *.ppu *.o *.obj *.OBJ *.or *.rsj *.rst *.sbr *.scc *.SID *.sln *.tar *.tds *.tlh*.tli *.trg *.vbw *.zip __history bak *.~* .#* I guess it is not valid to split the list on several lines in they config file? I tried to use a backslash character as a line continuation for "global-ignores" and it did not work. Apparently you are stuck with a very long line here. I don't know if anyone else has complained about it or if an enhancement request would be seen favorably by the Subversion developers. You could shorten the line a bit by reducing the number of spaces between words, and on Windows the names should be case-insensitive so that you can remove entries that differ only in case. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA EDA Software Developer, Expert Witness www.chapman-consulting-sj.com
Re: svnignore?
On Dec 29, 2017, at 12:55, Bo Berglund wrote: > I guess it is not valid to split the list on several lines in they > config file? I've never heard of that being possible.
Re: svnignore?
Ryan Schmidt wrote on Fri, 29 Dec 2017 14:05 -0600: > > On Dec 29, 2017, at 12:55, Bo Berglund wrote: > > > I guess it is not valid to split the list on several lines in they > > config file? > > I've never heard of that being possible. It doesn't seem to be (to my surprise), but the following does work: [miscellany] gi1 = foo1 foo2 gi2 = bar1 bar2 global-ignores = %(gi1)s %(gi2)s That's equivalent to [miscellany] global-ignores = foo1 foo2 bar1 bar2 .
Re: svnignore?
On 30.12.2017 00:27, Daniel Shahaf wrote: > Ryan Schmidt wrote on Fri, 29 Dec 2017 14:05 -0600: >> On Dec 29, 2017, at 12:55, Bo Berglund wrote: >> >>> I guess it is not valid to split the list on several lines in they >>> config file? >> I've never heard of that being possible. > It doesn't seem to be (to my surprise), but the following does work: > > [miscellany] > gi1 = foo1 foo2 > gi2 = bar1 bar2 > global-ignores = %(gi1)s %(gi2)s > > That's equivalent to > > [miscellany] > global-ignores = foo1 foo2 bar1 bar2 > > . Yes and this also works: [miscellany] global-ignores = foo1 foo2 bar1 bar2 Note the space at the beginning of the continuation lines. The syntax of Subversion config files is compatible with https://docs.python.org/2/library/configparser.html -- Brane
Re: svnignore?
On 12/29/2017 8:56 PM, Branko Čibej wrote: On 30.12.2017 00:27, Daniel Shahaf wrote: Ryan Schmidt wrote on Fri, 29 Dec 2017 14:05 -0600: On Dec 29, 2017, at 12:55, Bo Berglund wrote: I guess it is not valid to split the list on several lines in they config file? I've never heard of that being possible. It doesn't seem to be (to my surprise), but the following does work: [miscellany] gi1 = foo1 foo2 gi2 = bar1 bar2 global-ignores = %(gi1)s %(gi2)s That's equivalent to [miscellany] global-ignores = foo1 foo2 bar1 bar2 . Yes and this also works: [miscellany] global-ignores = foo1 foo2 bar1 bar2 Note the space at the beginning of the continuation lines. The syntax of Subversion config files is compatible with https://docs.python.org/2/library/configparser.html Is this documented in The Book? I was looking at http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html today and it made no mention of this. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA EDA Software Developer, Expert Witness www.chapman-consulting-sj.com
Re: svnignore?
On 30.12.2017 06:23, David Chapman wrote: > On 12/29/2017 8:56 PM, Branko Čibej wrote: >> On 30.12.2017 00:27, Daniel Shahaf wrote: >>> Ryan Schmidt wrote on Fri, 29 Dec 2017 14:05 -0600: On Dec 29, 2017, at 12:55, Bo Berglund wrote: > I guess it is not valid to split the list on several lines in they > config file? I've never heard of that being possible. >>> It doesn't seem to be (to my surprise), but the following does work: >>> >>> [miscellany] >>> gi1 = foo1 foo2 >>> gi2 = bar1 bar2 >>> global-ignores = %(gi1)s %(gi2)s >>> >>> That's equivalent to >>> >>> [miscellany] >>> global-ignores = foo1 foo2 bar1 bar2 >>> >>> . >> Yes and this also works: >> >> [miscellany] >> global-ignores = >> foo1 foo2 >> bar1 bar2 >> >> >> Note the space at the beginning of the continuation lines. The syntax of >> Subversion config files is compatible with >> https://docs.python.org/2/library/configparser.html > > Is this documented in The Book? I was looking at > http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html > today and it made no mention of this. I don't know if it's documented. Omissions should be reported to the book authors, see the "Feedback/Contributing" section here: http://svnbook.red-bean.com/ -- Brane
Re: svnignore?
On Sat, 30 Dec 2017 05:56:17 +0100, Branko ?ibej wrote: > >Yes and this also works: > >[miscellany] >global-ignores = > foo1 foo2 > bar1 bar2 This is what I tried and failed because I did not realize that it is not enough to just remove the comment char from the template config file to activate a value line, one must remove everything before the identifier. It must start at column 1... >Note the space at the beginning of the continuation lines. The syntax of >Subversion config files is compatible with >https://docs.python.org/2/library/configparser.html So here the leading whitespace on continuation lines is 4 characters wide. It seems like the requirement is one or more leading spaces for a line to be recognized as a continuation. The example uses 4 space characters but afaict this example is legal (4, 2, 3 whitespace chars and a comment line): global-ignores = pop1 pop2 foo1 foo2 bar1 bar2 # Added these values too: chuck1 chuck2 -- Bo Berglund Developer in Sweden
Re: svnignore?
Bo Berglund wrote on Sat, 30 Dec 2017 08:51 +0100: > On Sat, 30 Dec 2017 05:56:17 +0100, Branko ?ibej > wrote: > > > > >Yes and this also works: > > > >[miscellany] > >global-ignores = > > foo1 foo2 > > bar1 bar2 Are you sure? I couldn't get continuation lines to take effect regardless of what I tried. (With/without text after the "=", with/without backslash, with single tab or single space at the start of the continuation line...)
Re: svnignore?
On 30.12.2017 09:31, Daniel Shahaf wrote: > Bo Berglund wrote on Sat, 30 Dec 2017 08:51 +0100: >> On Sat, 30 Dec 2017 05:56:17 +0100, Branko ?ibej >> wrote: >> >>> Yes and this also works: >>> >>> [miscellany] >>> global-ignores = >>> foo1 foo2 >>> bar1 bar2 > Are you sure? I couldn't get continuation lines to take effect > regardless of what I tried. (With/without text after the "=", > with/without backslash, with single tab or single space at the start of > the continuation line...) Don't know what you were trying but see parse_option() and parse_value_continuation_lines() in subversion/libsvn_subr/config_file.c. -- Brane
Re: svnignore?
Branko Čibej wrote on Sat, 30 Dec 2017 10:09 +0100: > Don't know what you were trying [[[ % cat ~/.subversion/config [miscellany] global-ignores = bar foo % touch foo bar ]]] > but see parse_option() and > parse_value_continuation_lines() in subversion/libsvn_subr/config_file.c. (lldb) p ctx->value->data (char *) $2 = 0x77e1d310 "bar oo" And if I «touch ./oo» then ./oo gets ignored and ./foo doesn't. We've got an off-by-one somewhere. Cheers, Daniel
Re: svnignore?
On Sat, 30 Dec 2017 08:31:05 +, Daniel Shahaf wrote: >Bo Berglund wrote on Sat, 30 Dec 2017 08:51 +0100: >> On Sat, 30 Dec 2017 05:56:17 +0100, Branko ?ibej >> wrote: >> >> > >> >Yes and this also works: >> > >> >[miscellany] >> >global-ignores = >> > foo1 foo2 >> > bar1 bar2 > >Are you sure? I couldn't get continuation lines to take effect >regardless of what I tried. (With/without text after the "=", >with/without backslash, with single tab or single space at the start of >the continuation line...) > I have now edited my file and it now looks as follows (actual line breaks): global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.a *.aps *.bak.clw *.db *.dbg *.dcu *.ddp *.dsk *.dti *.err *.exp *.gid *.gz *.identcache *.ilk *.jar *.lnk *.local *.log *.lps *.lrt *.mod *.ncb *.ocx *.opt *.pch *.pjt *.plg *.pdb *.ppu *.obj *.or *.rsj *.rst *.sbr *.scc *.sln *.tar *.tds *.tlh *.tli *.trg *.vbw *.zip __history bak *.~* .#* When I create a new file in a non-versioned directory with extension .jar (3rd continuation line above) then SmartSVN does not show it unless I change the display filter to show also ignored files. So I am pretty sure the local version does work with line continuation. -- Bo Berglund Developer in Sweden
Re: svnignore?
Bo Berglund wrote on Sat, 30 Dec 2017 11:25 +0100: > So I am pretty sure the local version does work with line > continuation. The bug exists only in 1.10 pre-releases; it doesn't exist in 1.9.x. You've found a regression. :-)
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
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.
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 Dienstag, 30. Oktober 2012 um 06:58 schrieben Sie: > Maybe I called our system the wrong name. It is a homemade system, and > here are some of the things that it does: Just to be clear: What you call your build system is used directly by the devs and something we can think of as some kind of assistant to get pre configured working copies, right? The devs start this assistant, choose whatever fits their need and afterwards it is checking out, setting up and compiling things etc. and during that process svn working copies are created with versioned files with local modifications which should be ignored in svn status and comparable operations. If I understood correctly and you don't have any naming or directory layout convention to ignore the best chance in my opinion is your "build system", as if it knows what it does automatically and should be ignored it should get capable of providing that information to svn. It could update the user wide configuration for ignore patterns of Subversion or specify paths to exclude for Tortoise etc. 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
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> Just to be clear: What you call your build system is used directly by > the devs and something we can think of as some kind of assistant to > get pre configured working copies, right? The devs start this > assistant, choose whatever fits their need and afterwards it is > checking out, setting up and compiling things etc. and during that > process svn working copies are created with versioned files with local > modifications which should be ignored in svn status and comparable > operations. That is almost correct. You got the nature of the system right, but it does not create versioned files with local modifications. It creates several unversioned files, which should be ignored as well. These files do not follow any naming or directory layout convention, their names and locations are freely specified as part of each project's specification, which is kept in versioned per-project configuration files. The unversioned files are the main problem. > If I understood correctly and you don't have any naming or directory > layout convention to ignore the best chance in my opinion is your > "build system", as if it knows what it does automatically and should > be ignored it should get capable of providing that information to svn. > It could update the user wide configuration for ignore patterns of > Subversion or specify paths to exclude for Tortoise etc. Yes, indeed, the system knows exactly what should be ignored given the current in-development projects and other configuration options. With CVS, it marked these files as ignored by locally editing the .cvsignore file inside each folder, which did not have any undesired effect. Now, with SVN, our first idea was to locally edit each folder's svn:ignore property. However, since svn:ignore is itself versioned, every folder is always inconveniently marked as locally modified (property change only) by SVN, because the list of ignored files is different depending on the chosen projects and configuration options. And now we're back at my first post, self-quoted below. I can't help but think that there should be an unversioned list of ignored file patterns (.svnignore local file or svn:localignore property or something like that) as well as the versioned svn:ignore property. (self-quote) > 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.
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 Dienstag, 30. Oktober 2012 um 14:54 schrieben Sie: > I > can't help but think that there should be an unversioned list of > ignored file patterns (.svnignore local file or svn:localignore > property or something like that) as well as the versioned svn:ignore > property. But there's none and unless you code this feature on your own you won't get it anytime soon, I guess. The only thing left is your build system and the already present configuration for the used Subversion client and TortoiseSVN. 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
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
On Tue, Oct 30, 2012 at 03:35:46PM +0100, Thorsten Schöning wrote: > Guten Tag Vitor Barata, > am Dienstag, 30. Oktober 2012 um 14:54 schrieben Sie: > > > I > > can't help but think that there should be an unversioned list of > > ignored file patterns (.svnignore local file or svn:localignore > > property or something like that) as well as the versioned svn:ignore > > property. > > But there's none and unless you code this feature on your own you > won't get it anytime soon, I guess. The only thing left is your build > system and the already present configuration for the used Subversion > client and TortoiseSVN. > > Mit freundlichen Grüßen, > > Thorsten Schöning Is editing the global-ignores setting in the Subversion configuration file, as already suggested by Thorsten in an earlier post, not an option? That's currently the only unversioned place where ignore settings can be configured. See http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html#svn.advanced.confarea.opts.config Can the build system output its files into a subdirectory with a known name which can then be ignored? It seems your use case is rather exceptional. I've rarely seen the need to ignore arbitrary files with names that aren't known in advance. However, it's clear that the current ignore system isn't well suited for this case, so maybe we should extend Subversion in some way to account for this.
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
> Is editing the global-ignores setting in the Subversion configuration file, > as already suggested by Thorsten in an earlier post, not an option? > > That's currently the only unversioned place where ignore settings can > be configured. See > http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html#svn.advanced.confarea.opts.config > > Can the build system output its files into a subdirectory with a known > name which can then be ignored? A large part of the automatically-generated files contain source-code for language binding (Lua to C, Java to C and others). The system generates these files with .c/.cpp/.h extensions (so they can't be ignored based on the extension), but it does not enforce any convention on their names or on which directory they should go, this is freely configurable in custom project configuration files. This means that right now there is no global pattern that could be used in the global-ignores subversion setting. Now, we _could_ change the system and make it enforce a known subdirectory and/or some naming convention for all the automatically-generated source files. The problem is that, since we are talking about actual source code files and even exported headers (possibly used by developers in other dev teams), this would also require a through verification in all #includes (maybe only includepaths, not sure if it would be enough though) that reference such files in all the code in our repository (and possibly those of other dev teams). It seems a big trouble to go through just because of SVN property modifications. > It seems your use case is rather exceptional. I've rarely seen the need > to ignore arbitrary files with names that aren't known in advance. > However, it's clear that the current ignore system isn't well suited > for this case, so maybe we should extend Subversion in some way to > account for this. The simplest and cleanest way I see to extend Subversion to account for this is to provide another special property, say svn:localignore, that would work exactly like svn:ignore, but that would be unversioned, so that it could be altered by automation systems like ours without making directories be marked as modified. Thanks for your suggestions, Thorsten Schöning, Bob Archer and Stefan Sperling. I'm still deciding the best way to avoid the problem on our side, and I'm still listening to other suggestions as well, but so far I still believe that an unversioned ignore property (or something like that) would be a useful (and harmless) addition to Subversion. I have seen similar feature requests (based on different scenarios) be rejected, though, so I will wait a little longer before I make a new official request.
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
On Tue, Oct 30, 2012 at 01:57:09PM -0200, Vitor Barata wrote: > A large part of the automatically-generated files contain source-code > for language binding (Lua to C, Java to C and others). The system > generates these files with .c/.cpp/.h extensions (so they can't be > ignored based on the extension), but it does not enforce any > convention on their names or on which directory they should go, this > is freely configurable in custom project configuration files. This > means that right now there is no global pattern that could be used in > the global-ignores subversion setting. We do exactly the same thing in Subversion itself, and we do have ignore patterns like *.c and so on within the bindings source directories. There doesn't seem to be any problem with this in our project. This command lists the patterns we use: svn propget -v -R svn:ignore https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings I'm not quite sure if you really understand the impact of svn:ignore. What behaviour are you expecting from the svn:ignore mechanism exactly, and how would the expected behaviour impact your workflow? Just to get a common misconception out of the way: Note that you can add files that match an ignore pattern to version control if you really want to. All ignore patterns do is suppress files from appearing in the output of 'svn status'. And some IDEs use ignore patterns to prevent some unversioned files from being suggested for commit but they should still allow such files to be added to version control. > > It seems your use case is rather exceptional. I've rarely seen the need > > to ignore arbitrary files with names that aren't known in advance. > > However, it's clear that the current ignore system isn't well suited > > for this case, so maybe we should extend Subversion in some way to > > account for this. > > The simplest and cleanest way I see to extend Subversion to account > for this is to provide another special property, say svn:localignore, > that would work exactly like svn:ignore, but that would be > unversioned, so that it could be altered by automation systems like > ours without making directories be marked as modified. Based on past experience, I would guess that this is probably not as simple as you imagine it to be, unfortunately. You are talking about a major feature addition, not some small fix. Subversion has no concept of an unversioned property yet. Such a concept would need to be added first which would require some design and implementation effort. A lot of work would need to be done to make sure this new kind of property interacts well with all other features of the system (status, diff, commit, update, ...). That means writing a lot regression tests to start with. This might turn out to be about as "simple" as the "file external" feature turned out to be. A very simple idea on the surface but very hard to get working correctly in all use cases, and we ended up frantically fixing a lot of new bugs related to the feature over the course of several months.
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'm not quite sure if you really understand the impact of svn:ignore. > What behaviour are you expecting from the svn:ignore mechanism exactly, > and how would the expected behaviour impact your workflow? We want the unversioned files to not show in svn status or in tortoiseSVN's "Add" command when invoked on directories which contain unversioned files. I'll talk to other devs to see if there are other expected behaviors. > Based on past experience, I would guess that this is probably not as > simple as you imagine it to be, unfortunately. You are talking about > a major feature addition, not some small fix. > > Subversion has no concept of an unversioned property yet. > Such a concept would need to be added first which would require some design > and implementation effort. A lot of work would need to be done to make sure > this new kind of property interacts well with all other features of the > system (status, diff, commit, update, ...). That means writing a lot > regression tests to start with. > > This might turn out to be about as "simple" as the "file external" feature > turned out to be. A very simple idea on the surface but very hard to get > working correctly in all use cases, and we ended up frantically fixing a > lot of new bugs related to the feature over the course of several months. Alright, I got the picture. Don't worry, I'll look deeper into the matter and make a good effort to make things work nicely on our side before asking for such a feature. See below. > We do exactly the same thing in Subversion itself, and we do have > ignore patterns like *.c and so on within the bindings source directories. > There doesn't seem to be any problem with this in our project. > This command lists the patterns we use: >svn propget -v -R svn:ignore > https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings The problem is that the C files automatically generated for bindings are often mixed with standard versioned C files... However, after further inspection here, it seems to me that the binding files could indeed be put in a separate directory without requiring any code to be changed. My main concern is with the exported header files, but their names don't seem to vary much with the target platform and other compilation options in our system. Maybe I can tell Subversion to ignore the headers individually and also a special "bindings" directory containing the implementations. I'm going to investigate this further, maybe there is a way to adapt our system without requiring code changes after all. I'll report here soon.
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
On Tue, Oct 30, 2012 at 12:55 PM, Vitor Barata wrote: > > The problem is that the C files automatically generated for bindings > are often mixed with standard versioned C files... However, after > further inspection here, it seems to me that the binding files could > indeed be put in a separate directory without requiring any code to be > changed. If they are automatically generated, why not automatically delete them when finished with them? Or, you might look into using a distributed build automation like Jenkins so the builds would happen in a separate workspace and the cruft doesn't get in the way of developer commits. -- Les Mikesell lesmikes...@gmail.com