> > 3) Do both. Good for automated scripts that create snapshots. Good for
> > starting from scratch.
> 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. :-)
You are right. I'm usually careful not to do it, but I have had this
The fact is, different people have different styles of working with
version control systems. 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.
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
> 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. As for
the files that are not ignored, it depends.
I believe that it would be nice to extend "svn cleanup" or "svn revert" to
remove non-versioned files. The reason is that the presence on versioned
files limits my ability to work with files using standard UNIX commands.
I cannot remove non-versioned files by "rm -rf". Compare this to the
editor - presence of versioned files doesn't affect my ability to edit
If svn takes "rm -rf" away from me, it should offer a replacement. 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).
Otherwise, I'll have to write Subversion Utilities, and post them on my
homepage near CVS Utilities.
I really hope that I'll not have to do so, because Subversion is natively
client-server, and already supports a number of local-only operations
(e.g. "svn add"), unlike cvs, where every command involves server in some
way, so doing something purely local would be unusual.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 26 23:55:51 2002