On 4/21/06, Tim Hill <tim.hill@realmgp.com> wrote:
>
> Ben Collins-Sussman wrote:
> > It's interesting where this thread has gone! I originally proposed a
> > tiny bookkeeping feature, based on the fact that I (and others) have
> > become addicted to said bookkeeping when using perforce every day. I
> > was initially worried that the discussion would start heading down a
> > path of "stop crawling the working copy, store changelists in
> > ~/.subversion/", which is a very perforce-like thing to do.
> >
> Indeed! Incidentally, I wasn't voting *for* any SCM methodology, I just
> wondered if that's where this was going.
>
> WRT the "shelf" idea, why shouldn't this just be an SVN command that can
> automatically "trim" a WC down to the minimum number of files or folders
> that hold all changes made to date? This should be possible just by
> looking at WC data (local operation), and after operation the trimmed WC
> *is* the shelf. Then, all the user needs to do is checkout a new WC for
> the next set of changes. To unshelf, all that's needed is to re-sync the
> shelved WC from the repo. This sounds a lot cheaper than "local
> checkins", both to implement and from the feature-bloat perspective.
>
> Does this make sense? If so I might expand this as a feature proposal
> and/or look at the code overhead to implement?
Well, while that would work, I would hate the network overhead on larger
projects (can anyone say GCC ?)
I have 12 files that were changed in some way and now you trim away
thousands of files to make the shelf? Pulling them back is "easy" other
than the network overhead.
A much better option would be if "svn diff" had an option to make a
full, subversion feature complete, diff file (maybe nothing like diff or
maybe exactly like diff) that could then be saved somewhere by the
user. Then, there would need to be some "svn apply diff.file" that
would apply the diff back into the repository. Think of it sort of like
a way to make a file that is what is needed to do a svn merge operation
with the only difference being that the diff/merge is based on the
differences within the WC and not two revisions in the repository.
Actually, in one thing I work on that would be generally useful if
the "svn diff" command with this extra option could work beyond just
the WC and with revisions in the repository. It would allow the packaging
of a change set/merge operation. (Basically, like diff/patch only with
properties and rename/move/copy operations enumerated correctly)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 24 20:59:07 2006