6 ms·

> I wanna make a small change to the code to add [Feature X], I’ll just make a little branch, alright? I suppose this is a product of growing up on Git. Growi

> I wanna make a small change to the code to add [Feature X], I’ll just make a little branch, alright? I suppose this is a product of growing up on Git. Growing up on SVN, I'd just add the feature. > I was looking for the SVN equivalent of .gitignore: A list of file patterns that do not get source-controlled, ever. \ It turned out that SVN’s ignoring mechanism is far more complicated than that.... You're perfectly able to use a '.svnignore' file, if you like. In fact, the "Ignoring unversioned files" chapter (http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html http://svnbook.red-bean.com/nightly/en/svn.advanced.props.sp...) describes how to import .cvsignore files, which are another predecessor to .gitignore files. (Note to OP: If you hated SVN, just stay far, far away from CVS). SVN gives you a lot more rope with respect to properties if you want to do more complex stuff with properties (and yes, you can probably hang yourself with this rope - see http://svnbook.red-bean.com/nightly/en/svn.ref.properties.html http://svnbook.red-bean.com/nightly/en/svn.ref.properties.ht... for some use cases). The list of file patterns that don't get version controlled is known by Subversion as the svn::ignore property. The property syntax is similar to that of .gitignore files; simple .gitignore files are likely to be 100% compatible (notable differences are: no comments (but if you have a file called '# These files are generated by the compiler', we have other problems), and no `/` character support). You set this property (like all properties in SVN) with the `svn propset` (aka `svn ps`) command. See http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.propset.html http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.propset... for documentation. You can use files as arguments to this command, and you can set it recursively. Run the following command (which doesn't seem baffling) in the root of your working copy to set your ignore properties from a global ignore file: svn propset --recursive --file .svnignore . Note that you'll need to run this command every time that you edit the .svnignore file.

burgerbrain 15y ago
I think the issues are: 1) "a global ignore file" 2) In subversion you have to run a 44 character long command with one subcommand, two flags, and two file arguments. In git you have to do.... nothing.
- parfe 15y ago
  So edit ~/.subversion/config and never deal with ignores again. Acting like subversion does this in a less than optimal way is ignoring what the command is actually doing. With subversion method you can check out a subtree. Git can do no such thing. I prefer git, but being able to check out say, only /project/doc/ or /project/static/images/, is useful in subversion.
  - burgerbrain 15y ago
    I'm saying that for myself, for my needs, subversion's way is less optimal. No acting required. I don't need to only check out certain trees in my.. [checks] 20MB repo. What I do need is a way to ignore a rotating handful of files.
- reemrevnivek 15y ago
  1) Git ignore is not a global (to the repository) file, either. Both SVN and Git have per-user (not per-repository) settings, and they have very similar functions. .gitignore is only global by common practice, according to http://www.kernel.org/pub/software/scm/git/docs/gitignore.html#_description http://www.kernel.org/pub/software/scm/git/docs/gitignore.ht... you can use: ...a .gitignore file in the same directory as the path, or in any parent directory, with patterns in the higher level files (up to the toplevel of the work tree) being overridden by those in lower level files down to the directory containing the file. A global .gitignore feature in the toplevel of the work tree is just one way of using the .gitignore feature. 2) If character count is important, svn ps -R -F i . is only 16 characters long, and does the same thing (if you name your file 'i', since we're golfing here). I readily admit that this is INFINITELY longer than the Git version.

burgerbrain 15y ago

I think the issues are: 1) "a global ignore file" 2) In subversion you have to run a 44 character long command with one subcommand, two flags, and two file arguments. In git you have to do.... nothing.

parfe 15y ago
So edit ~/.subversion/config and never deal with ignores again. Acting like subversion does this in a less than optimal way is ignoring what the command is actually doing. With subversion method you can check out a subtree. Git can do no such thing. I prefer git, but being able to check out say, only /project/doc/ or /project/static/images/, is useful in subversion.
- burgerbrain 15y ago
  I'm saying that for myself, for my needs, subversion's way is less optimal. No acting required. I don't need to only check out certain trees in my.. [checks] 20MB repo. What I do need is a way to ignore a rotating handful of files.
reemrevnivek 15y ago
1) Git ignore is not a global (to the repository) file, either. Both SVN and Git have per-user (not per-repository) settings, and they have very similar functions. .gitignore is only global by common practice, according to http://www.kernel.org/pub/software/scm/git/docs/gitignore.html#_description http://www.kernel.org/pub/software/scm/git/docs/gitignore.ht... you can use: ...a .gitignore file in the same directory as the path, or in any parent directory, with patterns in the higher level files (up to the toplevel of the work tree) being overridden by those in lower level files down to the directory containing the file. A global .gitignore feature in the toplevel of the work tree is just one way of using the .gitignore feature. 2) If character count is important, svn ps -R -F i . is only 16 characters long, and does the same thing (if you name your file 'i', since we're golfing here). I readily admit that this is INFINITELY longer than the Git version.