Re: svn:ignore of checked in files and commit
On Wed, 15 Apr 2020 13:53:07 +0200
Branko Čibej wrote:
> I don't remember svn:ignore *ever* working the way you describe. Can you
> tell us which version of Subversion you were using? Are you absolutely
> sure it wasn't modified to behave as you describe?
That was like 10-15 years ago. I don't remember which version we
used back then.
> Like I said, it did not change. Files that are already
> version-controlled cannot be ignored. This was part of the original
> svn:ignore design spec, and the behaviour is actually based on .cvsignore.
Hmmm.. could it be that we were relying on a bug?
> > Is there a workaround that we can use?
>
> Sure, don't commit the files that you don't want in the repository.
> Instead, create a template that each user can rename to an (ignored)
> local name.
Yes, but mistakes happen. This is a project we are doing together with
a bunch of computer scientists. These are not computer savy people!
I'm glad we are using any SCM in the first place and not some Dropbox
with zip files or something.
Seem's like I have to think about changing our workflow..
Thanks a lot!
Attila Kinali
--
Science is made up of so many things that appear obvious
after they are explained. -- Pardot Kynes
svn:ignore of checked in files and commit
Hi, In the days of old, like several years back... When we had files that needed to be edited localy for each user/developer, we used to check them in normally, then set svn:ignore to ignore those files. This would result `svn commit` to ignore those files unless forced to by explicitly mentioning the filename (e.g., `svn commit ignoredfile`). Apparently this doesn't work anymore and svn commit happily still uses the ignored file and commits it... causing problems. Is there a specific reason this behaviour changed? Is there a workaround that we can use? Shall I submit a bugreport for this? Thanks and chocolaty greetings! Attila Kinali -- The bad part of Zurich is where the degenerates throw DARK chocolate at you.
Re: Software Subversion
On Fri, 3 Feb 2012 10:12:08 -0500 Nico Kadel-Garcia nka...@gmail.com wrote: On Fri, Feb 3, 2012 at 10:01 AM, Attila Kinali att...@kinali.ch wrote: Other than that issue, subversion is GPL and it's restrictions apply. You can find ample descriptions how these apply to comercial enviroments. Just google for them. No, it's an Apache license: Oops... right... sorry, my fault Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago?
Re: Software Subversion
On Fri, 3 Feb 2012 12:39:18 -0300 supp...@avibras.com.br wrote: Boa tarde, Preciso saber se o software Subversion é free para Windows 2003 e uso corporativo? Ich will ja nicht unhöflich sein, aber Englisch ist sonst die Sprache der Wahl, wenn man international kommuniziert. Auf Protugisisch wirst du leider nicht viel erfolg haben. Other than that issue, subversion is GPL and it's restrictions apply. You can find ample descriptions how these apply to comercial enviroments. Just google for them. 今度英語で書いてください Attila Kinali -- The trouble with you, Shev, is you don't say anything until you've saved up a whole truckload of damned heavy brick arguments and then you dump them all out and never look at the bleeding body mangled beneath the heap -- Tirin, The Dispossessed, U. Le Guin
svn ls/co -r rev does not work on deleted or moved directories
Moin, Setup: 1) create a repo with a few directories 2) commit some stuff 3) delete a directory at revision 42 4) commit some more stuff 5) do an svn co -r 41 svn://path/to/deleted/dir - this will fail with a file/directory not found error Interestingly, using the @ notation svn co svn://path/to/deleted/d...@41 works fine. Same is true for svn ls, using -rnum in svn:externals properties and probably a few other places as well. I had a look at the issue tracker but couldnt find any related entry. Attila Kinali -- If you want to walk fast, walk alone. If you want to walk far, walk together. -- African proverb
regression: commiting a property change fails on windows, when working copy is on a samba share
Hi, System: Windows XP svn 1.6.9 (collab) tortoise 1.6.7, build 18415 We upgraded two weeks ago from svn 1.5.9 to 1.6.9. Everything done here worked fine with 1.5.9. When the working copy is on a samba(3.2.5 debian/stable) share, editing and commiting a property fails with this error message: --- Commit Y:\work\scilab Commit succeeded, but other errors follow: Error bumping revisions post-commit (details follow): In directory 'Y:\work\scilab' Error processing command 'committed' in 'Y:\work\scilab' Can't move 'Y:\work\scilab\.svn\dir-props' to 'Y:\work\scilab\.svn\dir-prop-base': Access is denied. --- Note: this is not a normal permission issue as all files have the right permissions (created by the user himself). Logging in on the samba server and commiting using the linux CLI client works. This also works using the svn 1.5.9 on windows. Only changes to properties fail, any other change works fine. Any later svn command fails due to a remaining lock in the working copy. svn cleanup fails with above error message if run on windows. (as said above, it works fine running it on linux in the same directory). My guess is, that svn has a file handle on dir-props open, while it tries to move it. Which windows will refuse because the file is on a remote file server. Can anyone confirm this bug? Thanks in advance Attila Kinali -- If you want to walk fast, walk alone. If you want to walk far, walk together. -- African proverb
