[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: permanently ignoring some modified files in a checkout

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 3 Sep 2008 14:23:12 -0400

These files are already in the repository? If not, you can put the
"svn:ignore" property on your directory, and then give it a list
(separated by new lines) of files to ignore. You can also use globbing
patterns too. See

However, this is for UNVERSIONED items -- that is stuff not in the
repository. I am not sure if there is a way to ignore changes to
versioned items.

If you're using Subversion 1.5 client, you can take a look at
changelists as a way to keep the changes you want to commit separate
from the changes you don't want to commit. See:

I'm not 100% happy with the way changelists are done because the
default action on the commit is to commit all changed files. What I
would prefer is the concept of a "default" changelist. If I put a file
in a changelist, it gets removed from the default changelist. Doing a
simple "svn commit" without specifying a changelist would just commit
the files in the default changelist.

That way, if I am in Nick's position, I could do a "svn co", and
immediately put the links into a special changelist, then I don't have
to worry about those files being accidentally committed.

What you should really do is have a "link generator" script and store
that in the repository. The script would be run whenever you generate
a build. It would version you links and allow the developer to specify
the base directory for those links. That way, you don't have to modify
the links and then hope you don't accidentally check in the changes.

Because I guarantee you that someone will accidentally commit a change
in the link files that will cause problems with the application.

David Weintraub
On Wed, Sep 3, 2008 at 2:00 PM, Ryan Schmidt
<subversion-2008c_at_ryandesign.com> wrote:
> Quoting Nick Jennings <nick_at_cmdwebsites.com>:
>> I have a local checkout of a project I'm working on, the code
>> makes heavy use of symlinks using absolute paths (such as linking to
>> /<project>/<foo>/<bar>/<file>). On the system /<project> is a symlink
>> to the master (live) checkout of the project. Basically there is a lot
>> of linking within the project and in order to be clear about where
>> things link to, the designer decided to use these absolute paths.
>> So, I'm developing on the same system, but obviously I want all the
>> symlinks to point to /<mycheckout>/* . I made a quick shell script to
>> re-link the files in my checkout and everything works great.
>> However: when I do an 'svn status' all the symlinks show up as M and of
>> course I never want to commit these files, (though I might want to
>> commit the files they link to). Is there any way to in effect ignore
>> all these symlinks? So when I do an 'svn status' I only see the files
>> that I've modified during my development?
>> I know it's kind of a strange request, but I'm trying to avoid setting
>> up an entire chroot system just for some quick development work.
> I see this as another case of this situation:
> http://subversion.tigris.org/faq.html#ignore-commit
> The answer is: do not put those symlinks into the repository. Instead, you
> could create a script which is in the repository, and the script creates the
> symlinks on the developer system to point to the right place. And add
> svn:ignore properties to the directories to ignore the unversioned symlinks.
> Or, use relative symlinks so that they always work, regardless of where the
> working copy is.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-03 20:23:36 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.