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

Re: [PATCH] Additions to INSTALL

From: Josef Wolf <jw_at_raven.inka.de>
Date: 2002-10-06 22:57:41 CEST

On Thu, Sep 26, 2002 at 05:55:14PM -0400, Pavel Roskin wrote:

> > This doesn't look like a good approach to solve that specific problem.
> > If I forgot to include with "svn add" some source file created by hand,
> > the last thing I'd like to do is to remove that file. :-)

Well said!

> I'm used to the idea "commit it or lose it",
> i.e. the working directory is an extrement unsafe place to keep my
> changes. If I spend 20 minutes or more editing some file, and I cannot
> commit it (i.e. it's still not ready), I make a copy outside the tree.

Besides other reasons, I use a SCM so that I need _not_ to copy sources
around to arbitrary places and forgetting the context in which they
were created.

> Other people may take a different approach, and they will suffer. They
> are suffering with CVS already, because "cvs up" merges files without
> asking permission, and there is no way to disable merge on update from the
> command line.

Huh? They _asked_ for merge when they issued "cvs up", since "cvs up"
actually _means_ to merge...

I was suffering with CVS, but this was definitely _not_ for _this_
reason.

> > I'd rather check the output of "svn st | grep '^?'" for important files.
> It should be safe in many cases to remove files that svn ignores.

How come you to deduce this? Any ignored files after "make clean"
deserve my attention. There are exactly three possibilities how such
files can spring in existance:

  1. I forgot to add them to the "make clean" target
  2. I forgot to "svn add" them.
  3. I created them so I have input/output-data for test-runs.

In the first two cases, I should fix my source. In the third case
(which happen rarely), I delete them when _I_ want. Chances are that I
even decide to "svn add" them after some modifications and extend
regression-tests this way. No need for automated deletion at all.

> I believe that it would be nice to extend "svn cleanup" or "svn revert" to
> remove non-versioned files.

There were examples posted to this thread how you could do this with a
little help from perl/sed/xargs.

> The reason is that the presence on versioned
> files limits my ability to work with files using standard UNIX commands.

Huh? Could you please explain this in detail?

> I cannot remove non-versioned files by "rm -rf".

Huh? Why not? There is nothing that keeps you from "rm -rf WC". If you
want to reconstruct the state as it was on checkout (as you mentioned
on your prevous mail), you could issue

   cd ..; rm -rf WC; svn co -r X http://never.mind/foo WC; cd WC

to get a really clean wc.

> Compare this to the
> editor - presence of versioned files doesn't affect my ability to edit
> any files.

And it doesn't affect your ability to manipulate them in any other
way. This restriction exists only in your mind.

> If svn takes "rm -rf" away from me, it should offer a replacement.

It doesn't take away "rm -rf" and it shoudn't offer replacements.

> That's
> especially true, since svn is aware of the ignored files, and it often
> makes sence to remove only ignored files (i.e. keep the new sources, but
> clean the build).

It might make sense in some rare situations. But in those situations
the posted solutions with help from perl/sed/xargs are possible.

> Otherwise, I'll have to write Subversion Utilities, and post them on my
> homepage near CVS Utilities.

Please do this. And please do not introduce redundant functionality
which would needlessly bloat the clean design of svn.

-- 
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 6 22:58:53 2002

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

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