You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Eugene Voytitsky <vi...@ukr.net> on 2004/12/07 23:11:26 UTC
svn:ignore vs. .cvsignore
I've moved to use SVN after 4 years of using CVS.
Yes, SVN is better than CVS in many aspects.
But by now I found at least one issue where CVS is more rich --
SVN doesn't support .svnignore file to specify local
per-directory (and of course per-user) ignore list.
Yes, I know 2 ways to specify ignores for SVN:
1. (server-side, global) by setting `svn:ignore` property for dir
2. (client-side, global) by editing %APPDATA%\Subversion\config
`global-ignores` property of [miscellany] section
And I even read the discussion
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=300438
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=300459
Essence of the discussion is:
"Everything you'd put into a .cvsignore can be put into the svn:ignore
property with the same results."
But I don't agree that result is absolutely the same.
Each of 2 possible SVN ways have disadvantages:
1-st way (server-side, global) may be useless when each team member has
its own stuffs to ignore. Obviously that letting each member ability
to edit/commit svn:ignore prop will lead to mess in repository soon.
2-nd way (client-side, global) is useless because of global leads to
inconvenience: I should specify all ignores for all my repositories
in single config file. Besides of inconvenience it may be also
impossible to apply the same ignore rules for all repositories.
.svnignore file support solves all disadvantages mentioned above.
Btw CVS supports all 3 ways to specify ignore list:
per-repository, per-user (in user home), and local (.cvsignore)
Does anyone share my opinion that .svnignore support isn't useless?
I have tried to open enhancement issue about this topic
http://subversion.tigris.org/issues/show_bug.cgi?id=2156
but the issue had been marked as invalid immediatelly. :(
--
Best regards,
Eugene Voytitsky
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by Jason Thaxter <th...@gmail.com>.
On Wed, 8 Dec 2004 14:44:35 -0500, Jason Thaxter <th...@gmail.com> wrote:
[snip]
> aren't necessarily the same. And the two extra steps could be
> eliminated with a simple wrapper script something like this:
> $EDITOR .cvsignore
> svn propset svn:ignore .
I forgot the '-F .cvsignore' of course...
> svn ci -N -m 'updating ignore' . cvsignore
>
> Hmm. I'll have to actually try that. I'm not sure about the -N, which
> I've never used. Anyway, sometimes the availability of cheap
> workarounds prevents the need for a feature like .svnignore.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by Jason Thaxter <th...@gmail.com>.
On 08 Dec 2004 00:44:28 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> > .svnignore file support solves all disadvantages mentioned above.
>
> I'm not following this. Could you describe in one sentence an
> 'ignore' feature you get with CVS that you don't get with Subversion?
>
I can: rsync plays nicely with .cvsignore, and Subversion is not easy
to use this way.
For example, if I have something new to ignore, I could put it into
.cvsignore and I'm done - if I'm using CVS. With Subversion, you have
to add the file to .cvsignore, check it in, then do the propset.
That's two extra, kinda irritating steps.
Of course, this lack could also be regarded as a feature if you
consider that what you want to sync and what you want to version
aren't necessarily the same. And the two extra steps could be
eliminated with a simple wrapper script something like this:
$EDITOR .cvsignore
svn propset svn:ignore .
svn ci -N -m 'updating ignore' . cvsignore
Hmm. I'll have to actually try that. I'm not sure about the -N, which
I've never used. Anyway, sometimes the availability of cheap
workarounds prevents the need for a feature like .svnignore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn:ignore vs. .cvsignore
Posted by Dale Worley <dw...@pingtel.com>.
You could set the svn:ignore properties on the directories and just not
check those changes in. But that makes recursive "svn ci" difficult. OTOH,
would it be possible to adjust a client to have this sort of behavior?
Isn't the implementation of svn:ignore actually done by the clients?
Dale
-----Original Message-----
From: Eugene Voytitsky [mailto:viy75@ukr.net]
Oh, David thanks a lot for your clarification:
I completely missed to note that .cvsignore isn't under version control!
And just this fact makes .cvsignore so attractive for people like me :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by Eugene Voytitsky <vi...@ukr.net>.
kfogel@collab.net wrote:
> David Waite <dw...@gmail.com> writes:
>
>>I can answer this, because I've seen people as well who miss
>>.cvsignore. Making .cvsignore self-referential and outside the
>>repository, each user is given the ability to adjust their own local
>>ignores, per-directory as they please.
Oh, David thanks a lot for your clarification:
I completely missed to note that .cvsignore isn't under version control!
And just this fact makes .cvsignore so attractive for people like me :)
> Ah -- in other words, there are .cvsignore files, they're just not
> under version control. Thanks.
Yes it is most important fact in discussed topic.
> Eugene, if you don't get a clear response one way or the other after a
> couple of days, I'd say just reopen 2156 and refer to this thread in
> the archives. But be warned that lack of clear response probably
> means no one is going to jump to solve the problem (sorry).
I got the point, thanks.
--
Best regards,
Eugene Voytitsky
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by kf...@collab.net.
David Waite <dw...@gmail.com> writes:
> I can answer this, because I've seen people as well who miss
> .cvsignore. Making .cvsignore self-referential and outside the
> repository, each user is given the ability to adjust their own local
> ignores, per-directory as they please.
Ah -- in other words, there are .cvsignore files, they're just not
under version control. Thanks.
I have no opinion about the enhancement request. Other developers may
respond with more interest/enthusiasm, or may not.
Eugene, if you don't get a clear response one way or the other after a
couple of days, I'd say just reopen 2156 and refer to this thread in
the archives. But be warned that lack of clear response probably
means no one is going to jump to solve the problem (sorry).
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by François Beausoleil <fb...@ftml.net>.
On 10/12/2004 03:09, David Waite wrote:
> Assuming that people really do have a need for local ignore behavior,
> it is very difficult to manage in subversion today. There is no way to
> separately commit file content changes vs. file property changes.
svn commit -N will commit just the prop changes in a folder.
Bye,
François
Re: svn:ignore vs. .cvsignore
Posted by David Waite <dw...@gmail.com>.
The project I saw this with was a Java project which standardized on a
build environment (ant) but not an editor/IDE (Eclipse v2 and v3,
JEdit, Netbeans, Emacs and possibly JDEE, vim ...). If Joe Smith
leaves, his development environment is useless anyway.
-David Waite
On Fri, 10 Dec 2004 09:32:48 -0600, Steve Greenland <st...@lsli.com> wrote:
> On Fri, Dec 10, 2004 at 01:09:04AM -0700, David Waite wrote:
>
>
> > So you are suggesting that even though the project has not
> > standardized on tools, the repository should be changed to accomidate
> > them via an ever-growing array of ignore patterns? It seems if
> > you truely are using a wide array of tools, this growth becomes
> > unmanageable - you cannot tell which patterns are actually in use, or
> > by which people. With the svn:ignore property it is also extremely
> > difficult (but certainly not impossible) to track down who added a
> > particular entry.
>
> If you development environment is that out-of-control, then the growth
> of your svn:ignore property is the least of your worries. What are you
> going to do when Joe Smith leaves, and you can no longer build his
> part of the project? I'm all for letting people use the tools they're
> comfortable with, but mostly what we're talking about here is things
> like editor backup files and other spurious stuff, and as the upstream
> poster says, if *any* of those conflict with filename patterns that need
> to be revision controlled, a localized svn:ignore is not going to help.
>
> So yes, add the patterns to the svn:ignore property. If you can't trust
> your developers to add proper log comments ("Added .*~ for emacs backup
> files"), then, again, you've got problems that are outside the scope of
> SVN.
>
> Steve
>
> --
> "Outlook not so good." That magic 8-ball knows everything! I'll ask
> about Exchange Server next.
> -- (Stolen from the net)
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by Steve Greenland <st...@lsli.com>.
On Fri, Dec 10, 2004 at 01:09:04AM -0700, David Waite wrote:
> So you are suggesting that even though the project has not
> standardized on tools, the repository should be changed to accomidate
> them via an ever-growing array of ignore patterns? It seems if
> you truely are using a wide array of tools, this growth becomes
> unmanageable - you cannot tell which patterns are actually in use, or
> by which people. With the svn:ignore property it is also extremely
> difficult (but certainly not impossible) to track down who added a
> particular entry.
If you development environment is that out-of-control, then the growth
of your svn:ignore property is the least of your worries. What are you
going to do when Joe Smith leaves, and you can no longer build his
part of the project? I'm all for letting people use the tools they're
comfortable with, but mostly what we're talking about here is things
like editor backup files and other spurious stuff, and as the upstream
poster says, if *any* of those conflict with filename patterns that need
to be revision controlled, a localized svn:ignore is not going to help.
So yes, add the patterns to the svn:ignore property. If you can't trust
your developers to add proper log comments ("Added .*~ for emacs backup
files"), then, again, you've got problems that are outside the scope of
SVN.
Steve
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by David Waite <dw...@gmail.com>.
On Fri, 10 Dec 2004 06:08:55 +0100, Branko Čibej <br...@xbc.nu> wrote:
> Sure, different tools produce different temporary files and I can
> understand that people want those files ignored, and that you can't
> force everyone on a project to use the same tools. But if ignore
> patterns that would catch those files can also catch artifacts that
> should be committed to the repository, then the tool that prouces them
> is dangerous to use anyway.
So you are suggesting that even though the project has not
standardized on tools, the repository should be changed to accomidate
them via an ever-growing array of ignore patterns? It seems if you
truely are using a wide array of tools, this growth becomes
unmanageable - you cannot tell which patterns are actually in use, or
by which people. With the svn:ignore property it is also extremely
difficult (but certainly not impossible) to track down who added a
particular entry.
With a standardized build environment, svn:ignore makes sense as a
property of the repository as it is part of the policy of the project.
The problem is that there aren't allowences for when this build
environment is not standardized - to require changes to the repository
to accomidate things which are part of the individual user environment
and will never be versioned seems.. backward to me.
Keep in mind that user-global ignore patterns are not suitable, as
some of their projects may standardize on the editor/project
system/toolchain they are having to maintain separately for others.
Assuming that people really do have a need for local ignore behavior,
it is very difficult to manage in subversion today. There is no way to
separately commit file content changes vs. file property changes.
(by the way, the most bizarre setup I have seen actually took the
ignored files and symlinked them to another directory under local
version control)
- David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by Branko Čibej <br...@xbc.nu>.
David Waite wrote:
>I can answer this, because I've seen people as well who miss
>.cvsignore. Making .cvsignore self-referential and outside the
>repository, each user is given the ability to adjust their own local
>ignores, per-directory as they please.
>
>
What I'd like to see is a real-world example (of a project?) where it
makes sense for some project members to have their own private ignores
and where adding these to svn:ignore breaks the WC for other project
members.
And then said members of said projects should take a deep breath and
think hard for a while about things like "teamwork" and what version
control is for, _then_ discuss this issue further.
Sure, different tools produce different temporary files and I can
understand that people want those files ignored, and that you can't
force everyone on a project to use the same tools. But if ignore
patterns that would catch those files can also catch artifacts that
should be committed to the repository, then the tool that prouces them
is dangerous to use anyway.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by David Waite <dw...@gmail.com>.
I can answer this, because I've seen people as well who miss
.cvsignore. Making .cvsignore self-referential and outside the
repository, each user is given the ability to adjust their own local
ignores, per-directory as they please.
-David Waite
On 08 Dec 2004 00:44:28 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> Eugene Voytitsky <vi...@ukr.net> writes:
>
>
> > Yes, I know 2 ways to specify ignores for SVN:
> > 1. (server-side, global) by setting `svn:ignore` property for dir
> > 2. (client-side, global) by editing %APPDATA%\Subversion\config
> > `global-ignores` property of [miscellany] section
> >
> > And I even read the discussion
> > http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=300438
> > http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=300459
> >
> > Essence of the discussion is:
> > "Everything you'd put into a .cvsignore can be put into the svn:ignore
> > property with the same results."
> >
> > But I don't agree that result is absolutely the same.
> > Each of 2 possible SVN ways have disadvantages:
> >
> > 1-st way (server-side, global) may be useless when each team member has
> > its own stuffs to ignore. Obviously that letting each member ability
> > to edit/commit svn:ignore prop will lead to mess in repository soon.
>
> I don't know why you call this "server-side". The situation you
> describe here is exactly the functionality .cvsignore files provide.
>
> > 2-nd way (client-side, global) is useless because of global leads to
> > inconvenience: I should specify all ignores for all my repositories
> > in single config file. Besides of inconvenience it may be also
> > impossible to apply the same ignore rules for all repositories.
> >
> > .svnignore file support solves all disadvantages mentioned above.
>
> I'm not following this. Could you describe in one sentence an
> 'ignore' feature you get with CVS that you don't get with Subversion?
>
> An example would help a lot here.
>
> > I have tried to open enhancement issue about this topic
> > http://subversion.tigris.org/issues/show_bug.cgi?id=2156
> > but the issue had been marked as invalid immediatelly. :(
>
> It was marked as invalid because we prefer to discuss issues here
> before filing them. See http://subversion.tigris.org/project_issues.html
> for why. It's nothing personal.
>
> -Karl
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:ignore vs. .cvsignore
Posted by kf...@collab.net.
Eugene Voytitsky <vi...@ukr.net> writes:
> Yes, I know 2 ways to specify ignores for SVN:
> 1. (server-side, global) by setting `svn:ignore` property for dir
> 2. (client-side, global) by editing %APPDATA%\Subversion\config
> `global-ignores` property of [miscellany] section
>
> And I even read the discussion
> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=300438
> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgId=300459
>
> Essence of the discussion is:
> "Everything you'd put into a .cvsignore can be put into the svn:ignore
> property with the same results."
>
> But I don't agree that result is absolutely the same.
> Each of 2 possible SVN ways have disadvantages:
>
> 1-st way (server-side, global) may be useless when each team member has
> its own stuffs to ignore. Obviously that letting each member ability
> to edit/commit svn:ignore prop will lead to mess in repository soon.
I don't know why you call this "server-side". The situation you
describe here is exactly the functionality .cvsignore files provide.
> 2-nd way (client-side, global) is useless because of global leads to
> inconvenience: I should specify all ignores for all my repositories
> in single config file. Besides of inconvenience it may be also
> impossible to apply the same ignore rules for all repositories.
>
> .svnignore file support solves all disadvantages mentioned above.
I'm not following this. Could you describe in one sentence an
'ignore' feature you get with CVS that you don't get with Subversion?
An example would help a lot here.
> I have tried to open enhancement issue about this topic
> http://subversion.tigris.org/issues/show_bug.cgi?id=2156
> but the issue had been marked as invalid immediatelly. :(
It was marked as invalid because we prefer to discuss issues here
before filing them. See http://subversion.tigris.org/project_issues.html
for why. It's nothing personal.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org