I like!
Something like this had been tossed around a bit before, I think we
were calling it "svn guess" then, though "sync" might be a better
name. One possibility: it could be interactive, asking the user about
each unknown entity encountered. I think there's a way to design
libsvn_client so that the prompting ability is supplied without
specifying whether it's a command line prompt, GUI prompt, or what
(using the usual callback/baton pattern).
Definitely post-1.0 (sorry, needed to be said), but early post-1.0.
It's a very nice feature, but not crucial for anyone and not something
CVS supplies either.
(Hmm, also it could be done with a wrapper script that parses the
output of "svn update"...)
Wanna stick it in IDEAS?
-K
Lee Burgess <lefty@red-bean.com> writes:
> Fitz and I were working on the client README, fleshing out commands
> and their options a couple nights ago. We came across and interesting
> idea (Fitz's really) for a feature that CVS does not have that
> Subversion might want to have (given that software can want anything).
> It's in the README, but I just wanted to draw attention to it to get
> some feedback from the group.
>
> Here is the snippet from the README:
>
> --cut--
>
> sync
> ====
>
> This is going to take a bit of explaining. Imagine an intelligent
> update that knows to add new files and remove files that you've
> removed, and all recursively (without having to svn add, svn rm, ad
> nauseam). More to come!
>
> --cut--
>
> We had originally thought that it might be an option to update, like:
>
> $ svn up --force
>
> But we reasoned that it might be better to have a separate command
> since it is so much more than just updating.
>
> So if I have a working copy like so:
>
> $ ls
> SVN/ main.c foo.c bar/
>
> where main.c is in the repository, foo.c needs a checkin and bar.c is
> absent from the repository.
>
> And I do:
>
> $ svn sync
>
> What happens is foo.c gets checked in and bar and its contents get
> automagically added and checked in.
>
> Likewise, if I had in my working copy a bat.c and previously removed
> it, it would also be automagically dealt with accordingly as if I had
> issued a separate "svn rm bat.c". (I don't recall at the moment if
> Subversion will require one to "svn ci" after "svn rm", but I don't
> think it does?).
>
> Anyway, the jist is that this could be a very powerful Subversion
> feature, allowing one to do a lot of working copy maintenance with
> fewer commands.
>
> And there is always the .svnignore file to take care of files you
> don't want svn to care about.
>
> This is a pretty rough description, but enough to generate feedback.
>
> Thoughts? Criticism? Pros? Cons?
>
> --
> Lee P. W. Burgess <<!>> Manipulate eternity. Power is a symphony:
> Programmer <<!>> elaborate, enormous, essential.
> Red Bean Software <<!>> Dream the moment with a fiddle in summer
> lefty@red-bean.com <<!>> and a knife in winter.
Received on Sat Oct 21 14:36:12 2006