This is a great idea -- Bruce, can you put it in IDEAS? Since it's
not something CVS supports, and adding it later won't break backwards
compatibility, I think it probably shouldn't be a 1.0 goal (as
attractive as it is, we have to prioritize of course).
-K
Bruce Korb <bkorb@sco.COM> writes:
> Lee Burgess wrote:
> > However, I also agree that it would be nice if cvs (svn) status had a
> > more terse form. I have found that the normal output of cvs status is
> > very useful. Yet, from the general concensus, it is just as useful to
> > have output that gives much simpler information that is still in the
> > realm of file "status".
> >
> > Rather than having a new command "svn changes", why not just have some
> > local options to "svn status": like a long form and a short form?
>
> Because `svn status' seems like a very convenient vehicle for
> supplying arbitrary information that a script may wish to extract.
> What if `svn status' had a standard, default display that was
> configured with a format string. That format string could be
> over-ridden with an option (``--format=....'') and we made an
> option alias or two for formats that were likely to be commonly
> used? Here is an approximation that would likely be abbreviated:
>
> --format="%{obj-name}: %{ver=TAG} vs. %{local-ver} is %{mod-state}\n"
>
> So, if TAG were associated with the 1234 version of object mumble,
> but the local copy were version 1222 but unchanged, you get:
>
> mumble: 1234 vs. 1222 is unchanged
Received on Sat Oct 21 14:36:13 2006