Our users *would* really love status'es and commits to be blazingly
fast. For example, for one of our trees if the import contained 4734
files, a WC of the same contains 17995 files. No wonder status and
commit take forever. I can see 2 benefits of working-copy changesets
(changelists in Perforce lingo)...
1. Users can segregate files they are currently working on into
change-sets for much better bug-fix management. In many environments
certain file are never committed but modified temporarily for
development purposes - these can be put into a "Don't checkin"
changeset.
The developer needn't sift through all modified files when the time
comes to check-in fix for a particular bug - just check-in that
changeset.
2. Status and commit would be *very* fast. In fact, contents of the
changeset would be the status.
regards,
-anir.
On Apr 2, 2005 11:24 PM, Josh Pieper <jjp@pobox.com> wrote:
> I think one of the advantages of this declared edit feature is that it
> allows status/diff gathering to be blazingly fast. 'svn status' can
> take absurdly long periods of time on large working copies. If there
> were an option to have read-only checkouts and have a 'svn edit'
> command make them read+write, Subversion could keep track of which
> files had been edited and significantly speed up status, diff, commit,
> etc. It would make svn usable on projects where working on only
> portions of a large tree is not practical.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 4 15:04:11 2005