> > I'm used to the idea "commit it or lose it", i.e. the working
> > directory is an extremely 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.
You don't need to copy sources around. Save the patches if you cannot or
don't want to apply them.
> > 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...
It means to update the sources and merge if necessary. The bad thing,
merge is often unexpected and requires manual work to recover from.
> > > 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.
That's right. But sometimes you just know that there is nothing
interesting in the working directory that could not be easily reproduced.
> > 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.
I'm using such script already. My point is that it would be nice to have
a command for that.
> > 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 omitted the obvious "if I don't want to interfere with the integrity of
the working directory and the repository".
The repository is fortunately well protected by the client-server
protocol, but the working directory is not protected. It is not like
Clearcase, when you mount the directory and the kernel tells you want you
can do and what you cannot do with the versioned files.
> > 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.
Firstly, it removes my local changes to the versioned files, something
that I may or may not wish. Secondly, it's impractical for large projects
and narrow data pipes.
> > Compare this to the editor - presence of versioned files doesn't
> > affect my ability to edit any files.
I meant, svn is designed is such way that it doesn't go crazy if I edit
the files under version control without locking. It is also tolerant to
the files it doesn't know about.
> And it doesn't affect your ability to manipulate them in any other
> way. This restriction exists only in your mind.
Again, I meant "without breaking the integrity of the versioning system".
> > 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.
Our development style is different. What is rare for you is common for
me.
> > 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.
Ok.
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 7 01:05:17 2002