You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Benjamin Pflugmann <be...@pflugmann.de> on 2002/11/06 17:11:13 UTC
svn cat (was: Re: svn up -p)
Hello.
On Wed 2002-11-06 at 04:28:22 -0800, Noel Yap wrote:
[...]
> Another thought that's flashed through my mind is that
> the soon-to-come "blame" is very similar to this
> functionality.
Funny. While reading the thread, I just came up with the
same idea. So, I second that.
> I believe "cat" is perfect (unless you're from
> windows), so, assuming "cat" is used, a "--verbose"
> flag could be passed to it to do "blame". (Just
> hashing out ideas before my morning coffee, so please
> feel free to bash them :-)
What I did not think of was to name it "cat". I think it is
a great idea, because I never liked "blame" (I don't
associate it with the task I want to solve - but we already
had that discussion). I like
svn cat -v
a lot more. Cool idea. I love it.
So... please never drink no coffee nomore. ;-)
Regards,
Benjamin.
Re: svn cat (was: Re: svn up -p)
Posted by kb...@gte.net.
Vladimir Prus wrote:
>
> Hmm... I've kinda started "svn up -p" and kinda did it, and "svn cat" is
> twice as super easy from that. I've no problem if somebody else does it,
> though. Kevin, are you interested in seeing my patch for "svn up -p"?
If you've already started/done it, then I don't need to do it. :-) It just
appeared that no one was going to do it and it was an itch that I felt should
be scratched (soon).
>
> And, BTW, it really seems the thread has died. I'd prefer single
> command for both "cat" and "ls" functionality, but only one person
> commented on
> that.
I don't really know enough to say if the 2 subcommands should be 1 or not.
But since I didn't see anyone else saying "I'll do it", I was willing to.
I'll be patient and wait for your work; but if you could send the patch to me,
I'd be very interested in seeing how you did parts of it, as a learning
experience. Getting up to speed on how some of this stuff works internally
seems very daunting. :-/
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Vladimir Prus <gh...@cs.msu.su>.
Ben Collins-Sussman wrote:
> kbrannen@gte.net writes:
>
>
>>>On Wed, 2002-11-06 at 14:59, Branko Čibej wrote:
>>>
>>>
>>>>"cat" would fetch a file and pipe it to the standard output.
>>>
>>I've tried to follow this thread to see where it would go, because I
>>find the feature highly useful and very missing. I'm not sure what
>>the final outcome was (the thread seems to have died off), but is
>>anyone working on it? If not, I think I might like to try, with a few
>>pointers on direction. :-)
>
>
> Go for it. It's super easy to do. All you need to do is write a new
> function, svn_client_cat(), which calls RA->get_file(). A perfect way
> to get your feet wet.
Hmm... I've kinda started "svn up -p" and kinda did it, and "svn cat" is
twice as super easy from that. I've no problem if somebody else does it,
though. Kevin, are you interested in seeing my patch for "svn up -p"?
And, BTW, it really seems the thread has died. I'd prefer single
command for both "cat" and "ls" functionality, but only one person commented on
that.
- Volodya
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2002-11-12 at 08:53, Ben Collins-Sussman wrote:
> > Sure, take a look at libsvn_client/switch.c:192 and below. There's a
> > call to RA->get_file() in there. Notice that first creates a unique
> > tmpfile and gets an apr_file_t back. Then it converts the apr_file_t
> > into an svn_stream_t. Then the stream object is given to
> > RA->get_file(), which pushes data into the stream.
> >
> > In your case, you probably just want to get an apr_file_t that
> > represents stdout, and convert that into a stream.
>
> What about keyword and newline translation?
You just HAD to open that can of worms, eh? :-)
Let's label that as "phase 2" of 'svn cat'. It's not trivial, but it
won't be that hard either. RA->get_file() is able to retrieve text,
props, or both. It's just a matter of looking at the svn:eol-style
and svn:keywords props, fetching the textdata into a tmpfile,
copy-and-translating into a 2nd tmpfile, dumping to the screen, then
deleting the tmpfiles. I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2002-11-12 at 08:53, Ben Collins-Sussman wrote:
> Sure, take a look at libsvn_client/switch.c:192 and below. There's a
> call to RA->get_file() in there. Notice that first creates a unique
> tmpfile and gets an apr_file_t back. Then it converts the apr_file_t
> into an svn_stream_t. Then the stream object is given to
> RA->get_file(), which pushes data into the stream.
>
> In your case, you probably just want to get an apr_file_t that
> represents stdout, and convert that into a stream.
What about keyword and newline translation?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Ben Collins-Sussman <su...@collab.net>.
kbrannen@gte.net writes:
> > Um, generally, yeah.... but why do you want to convert an apr_file_t
> > into an svn_stringbuf_t?
>
> Because I was thinking that I needed to stick the file into a buffer
> to be passed back to whoever called svn_client_cat and *that* function
> would print to STDOUT. I was going that direction because it occurred
> to me that STDOUT may be relative. For the cmdline tool, it truely is
> the stream STDOUT, but for a GUI tool, it might be some browser window
> (or some specified filename more likely).
Oh jeez, you're right!
svn_client_cat() isn't allowed to assume that the svn_stream_t is
stdout. Instead, the client application must create the stdout stream
object, and pass it *into* svn_client_cat(). That's pretty simple.
Just add a stream argument to svn_client_cat().
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Branko Čibej <br...@xbc.nu>.
kbrannen@gte.net wrote:
> Because I was thinking that I needed to stick the file into a buffer
> to be passed back to whoever called svn_client_cat and *that* function
> would print to STDOUT.
Eeek!
> I was going that direction because it occurred to me that STDOUT may
> be relative. For the cmdline tool, it truely is the stream STDOUT,
> but for a GUI tool, it might be some browser window (or some specified
> filename more likely). The part that bothers me about this is that
> while it works for the vast majority of the cases, if this was done to
> a *big* file, the results would not be pretty. :-) I think the
> solution would be to have the calling function pass in a stream for
> the svn_client_cat to write to, hence removing the "exhaust memory"
> problem.
Yes, do use a stream. We even have generic streams in Subversion, for
exactly that purpose; see subversion/include/svn_io.h.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by kb...@gte.net.
Ben Collins-Sussman wrote:
> [Keeping this thread on the public list. There are many developers
> who can help, not just me. :-) ]
>
> kbrannen@gte.net writes:
...
>>I've started down the path of looking at the "ls" functionality, as it
>>seems somewhat similiar. I've gotten:
>
>
> Excellent. 'ls' is exactly what I was going to recommend you imitate.
>
>
>>svn_ra_init_ra_libs
>>svn_ra_get_ra_library
>>svn_client__open_ra_session
>>svn_client__get_revision_number
>>ra_lib->check_path
>>if file
>> /* and now it gets shaky */
>> ???
>> ra_lib->get_file
>> ???
>> svn_stringbuf_from_aprfile
>> ra_lib->close
>>
>>I think I somehow need to get to svn_stringbuf_from_aprfile() so I can
>>put the file in that and pass it back to svn_client_cat for it to
>>fwrite(..., STDOUT).
>>
>>1. Am I heading in the right direction?
>
>
> Um, generally, yeah.... but why do you want to convert an apr_file_t
> into an svn_stringbuf_t?
Because I was thinking that I needed to stick the file into a buffer to be
passed back to whoever called svn_client_cat and *that* function would print
to STDOUT. I was going that direction because it occurred to me that STDOUT
may be relative. For the cmdline tool, it truely is the stream STDOUT, but
for a GUI tool, it might be some browser window (or some specified filename
more likely). The part that bothers me about this is that while it works for
the vast majority of the cases, if this was done to a *big* file, the results
would not be pretty. :-) I think the solution would be to have the calling
function pass in a stream for the svn_client_cat to write to, hence removing
the "exhaust memory" problem.
>
>
>>2. Can you point me to a file that I can look at that implements the
>>get_file (& supporting code) in a way I need it? (IOW do you know of
>>something like this off the top of your head as I don't mean for you
>>to spend more than a minute or so on this).
>
>
> Sure, take a look at libsvn_client/switch.c:192 and below. There's a
> call to RA->get_file() in there. Notice that first creates a unique
> tmpfile and gets an apr_file_t back. Then it converts the apr_file_t
> into an svn_stream_t. Then the stream object is given to
> RA->get_file(), which pushes data into the stream.
>
> In your case, you probably just want to get an apr_file_t that
> represents stdout, and convert that into a stream.
Thanks! I'll look at that. Though it now seems that Vladimir is taking care
of it, still, it gives me a chance to learn on something easy which will allow
me to consider doing other small tasks as I feel more confident. Looking at
all the apr* functions makes me feel like I'm in a maze of twisty passages all
different. :-)
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Ben Collins-Sussman <su...@collab.net>.
[Keeping this thread on the public list. There are many developers
who can help, not just me. :-) ]
kbrannen@gte.net writes:
> Ben Collins-Sussman wrote:
> > kbrannen@gte.net writes:
> >
> >>>On Wed, 2002-11-06 at 14:59, Branko Čibej wrote:
> >>>
> >>>
> >>>>"cat" would fetch a file and pipe it to the standard output.
> >>>
> >>I've tried to follow this thread to see where it would go, because I
> >>find the feature highly useful and very missing. I'm not sure what
> >>the final outcome was (the thread seems to have died off), but is
> >>anyone working on it? If not, I think I might like to try, with a few
> >>pointers on direction. :-)
> > Go for it. It's super easy to do. All you need to do is write a new
> > function, svn_client_cat(), which calls RA->get_file(). A perfect way
> > to get your feet wet.
> >
>
> Thanks! I think... :-) Yes, conceptually it's very easy. However,
> I'm running into the proverbial brick wall of all newbie's to a
> project. There's all these APIs and it's really tough to know what to
> call when. Is there something written that I need to be reading that
> I haven't found yet?
>
> I've started down the path of looking at the "ls" functionality, as it
> seems somewhat similiar. I've gotten:
Excellent. 'ls' is exactly what I was going to recommend you imitate.
>
> svn_ra_init_ra_libs
> svn_ra_get_ra_library
> svn_client__open_ra_session
> svn_client__get_revision_number
> ra_lib->check_path
> if file
> /* and now it gets shaky */
> ???
> ra_lib->get_file
> ???
> svn_stringbuf_from_aprfile
> ra_lib->close
>
> I think I somehow need to get to svn_stringbuf_from_aprfile() so I can
> put the file in that and pass it back to svn_client_cat for it to
> fwrite(..., STDOUT).
>
> 1. Am I heading in the right direction?
Um, generally, yeah.... but why do you want to convert an apr_file_t
into an svn_stringbuf_t?
> 2. Can you point me to a file that I can look at that implements the
> get_file (& supporting code) in a way I need it? (IOW do you know of
> something like this off the top of your head as I don't mean for you
> to spend more than a minute or so on this).
Sure, take a look at libsvn_client/switch.c:192 and below. There's a
call to RA->get_file() in there. Notice that first creates a unique
tmpfile and gets an apr_file_t back. Then it converts the apr_file_t
into an svn_stream_t. Then the stream object is given to
RA->get_file(), which pushes data into the stream.
In your case, you probably just want to get an apr_file_t that
represents stdout, and convert that into a stream.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Ben Collins-Sussman <su...@collab.net>.
kbrannen@gte.net writes:
> > On Wed, 2002-11-06 at 14:59, Branko Čibej wrote:
> >
> >>"cat" would fetch a file and pipe it to the standard output.
>
> I've tried to follow this thread to see where it would go, because I
> find the feature highly useful and very missing. I'm not sure what
> the final outcome was (the thread seems to have died off), but is
> anyone working on it? If not, I think I might like to try, with a few
> pointers on direction. :-)
Go for it. It's super easy to do. All you need to do is write a new
function, svn_client_cat(), which calls RA->get_file(). A perfect way
to get your feet wet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Noel Yap <ya...@yahoo.com>.
--- Ben Collins-Sussman <su...@collab.net> wrote:
> Noel Yap <ya...@yahoo.com> writes:
> > Ben, does RA->get_file() work this way already?
>
> No, because it's part of the the RA (Repository
> Access) vtable. By
> definition, it only gets a file from a repository.
> To get a file's
> local contents, just apr_file_open(). Of course I
> can think of at
> least two plausible behaviors for 'svn cat
> localfile': either 1. cat
> the hidden text-base of localfile, or 2. just
> convert localfile into a
> url, and still get some version of the file from the
> repository. I'm
> not sure what you were thinking of.
Sorry I wasn't clear enough.
I expect "svn cat -r REV file" to output the contents
of file at revision REV and "svn cat file" to behave
like "svn cat -r BASE file". Does this make sense?
Since the base revision is cached locally, it would be
better if "svn cat file" used that cache. So, a
first-pass implementation that comes to mind is:
1. If no revision is specified, cat the cached
base-revision file. (If "blame" is to be implemented
with "cat -v" in the future, it would have to query
the server.)
2. Otherwise, convert the filename to a URL and query
the server.
The above makes sense to me, but as experience has
often shown, what makes sense to me can be complete
nonsense to someone else :-)
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Ben Collins-Sussman <su...@collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> --- kbrannen@gte.net wrote:
> > For the moment, let's assume it's called "svn cat";
> > the real name can be
> > worked out. If we do:
> >
> > svn cat REPOS/file
> >
> > then the file should be printed to STDOUT. I think
> > it's also reasonable to
> > expect "-r rev" might appear in there too. :-)
>
> As a convenience, "svn cat" should also work when
> specifying working directory files. (It'll save on
> typing :-)
>
> Ben, does RA->get_file() work this way already?
No, because it's part of the the RA (Repository Access) vtable. By
definition, it only gets a file from a repository. To get a file's
local contents, just apr_file_open(). Of course I can think of at
least two plausible behaviors for 'svn cat localfile': either 1. cat
the hidden text-base of localfile, or 2. just convert localfile into a
url, and still get some version of the file from the repository. I'm
not sure what you were thinking of.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Noel Yap <ya...@yahoo.com>.
--- kbrannen@gte.net wrote:
> For the moment, let's assume it's called "svn cat";
> the real name can be
> worked out. If we do:
>
> svn cat REPOS/file
>
> then the file should be printed to STDOUT. I think
> it's also reasonable to
> expect "-r rev" might appear in there too. :-)
As a convenience, "svn cat" should also work when
specifying working directory files. (It'll save on
typing :-)
Ben, does RA->get_file() work this way already?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by kb...@gte.net.
> On Wed, 2002-11-06 at 14:59, Branko Čibej wrote:
>
>>"cat" would fetch a file and pipe it to the standard output.
I've tried to follow this thread to see where it would go, because I find the
feature highly useful and very missing. I'm not sure what the final outcome
was (the thread seems to have died off), but is anyone working on it? If not,
I think I might like to try, with a few pointers on direction. :-)
For the moment, let's assume it's called "svn cat"; the real name can be
worked out. If we do:
svn cat REPOS/file
then the file should be printed to STDOUT. I think it's also reasonable to
expect "-r rev" might appear in there too. :-)
For a first pass, I'd be tempted to make it return nothing if you hand it a
directory, except maybe a message like "can't cat a directory" to STDERR, and
exit with 1. Something more intelligent can be done, but for the moment, I
really don't care to get into that "mess" and would like to avoid the issue.
This appears to be issue #399.
So, is the above a reasonable approach and thing to do? Is anyone else
already working on this?
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2002-11-06 at 14:59, Branko Čibej wrote:
> "cat" would fetch a file and pipe it to the standard output. "blame"
> would print a line-by-line annotation, but only for text files. I fail
> to see how those are even remotely similar, except in that they write
> something to stdout.
I observe that in Unix, "cat -n" and "cat -b" also only apply to text
files. So a feature isn't rendered not-remotely-similar-to-cat just
because it only applies to text.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Noel Yap <ya...@yahoo.com>.
--- Benjamin Pflugmann <be...@pflugmann.de>
wrote:
> Maybe the different opinions come from why we use
> blame. I use cvs
> annotate just as what I described, a more
> informative listing of the
> file at hand.
Just today, I used "cvs ann", not to see who broke
something, but rather to see when code was last
changed. The fact that it hadn't been touched since
before Y2k meant to me that it was stable and the
problem I'm hunting down most probably existed
elsewhere. I think creating "svn cat -v" or "svn cat
--verbose" in place of "svn blame" would make the
command have a more exact meaning to its functionality
(with the PCness to boot :-).
Noel
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hello.
On Wed 2002-11-06 at 20:59:25 +0100, Branko ??ibej wrote:
[...]
> > >Another thought that's flashed through my mind is that
> > >the soon-to-come "blame" is very similar to this
> > >functionality.
> >
> > Funny. While reading the thread, I just came up with the
> > same idea. So, I second that.
> >
> These are very strange and disturbing associations.
>
> "cat" would fetch a file and pipe it to the standard output. "blame"
> would print a line-by-line annotation, but only for text files.
And? There are a lot of UNIX command line tools that only work for
text files (reasonably). E.g. the --number-nonblank, --show-ends,
--number, --squeeze-blank options of (GNU) cat only works for text
files, either.
The fact that currently diffs (that is what blame boils down to) are
hard to do for non-text files is not a failure in the association.
> I fail to see how those are even remotely similar, except in that
> they write something to stdout.
Oh, they have more in common. They do not only write something to
stdout. That "something" is the same, indeed: The content of the
file. blame/cat-v is just more verbose by printing out some metadata,
additionally. For the idea it is irrelevant that this metadata may be
hard to generate.
Or the other way around: cat makes no sense for binary data, except
for redirecting it into some file or other program. The terminal is
not able to handle binary data, e.g. a MS Word document. You could
consider the terminal to be an implicit display-tool for text. And we
have a text-oriented diff. Having both, we can generate blame/cat-v
output for text, already.
In theory, there is nothing that prevents implementing a diff for MS
Word documents and therefore implementing blame/cat-v by generating a
new MS Word doc at the end (the metadata being inserting into the
document itself). MS Word or a Word viewer could be the display tool.
I do not mean to really go that route by any way. I just wanted to
show, that IMHO the concept is not that strange. Currently, we "just"
lack the tools to have blame/cat-v work on other formats.
Maybe the different opinions come from why we use blame. I use cvs
annotate just as what I described, a more informative listing of the
file at hand. You seem to me more concerned about the metadata or the
task you try to solve with it. Or I did I misunderstand you?
Regards,
Benjamin.
RE: svn cat (was: Re: svn up -p)
Posted by Barry Scott <ba...@ntlworld.com>.
You are lucky you have worked with people that appreciate
the joke.
If I can find a word that you like would you use it? Or
is this joke staying regardless?
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Branko Čibej <br...@xbc.nu>.
Barry Scott wrote:
>I keep seeing the "blame" command being talked about. That
>is a terrible name for a command. In many organisations its
>seen as bad practice to "blame" developers for bugs. I'd have
>chosen a command name like "annotate".
>
Oh my...I can't understand why people get so stuck-up about a word.
Personally I'd never work for a company where humour was forbidden. Such
companies should first forbid Emacs, because it has _games_ built in
(eek! who'll do the work if they keep playing?).
Sure, seeing incompetent managers blame developers for bugs is tasteless
(and for all I care incompetent managers should have their feet chained
to a block of concrete in preparation for the necessary dunking). But
developers "svn blame"'ing each other is a joke, and I highly recommend
that because it promotes team spirit, so there!
Besides, "svn blame" isn't just for finding bugs, and the word
"annotate" implies adding annotations, which is more likely to confuse
people.
There will be a command called "svn blame".
There will be an alias for that command, "svn praise", for those
precious rare occasions.
I have Spoken, and the world trembles.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame game (svn cat (was: Re: svn up -p)
Posted by Noel Yap <ya...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Noel Yap <ya...@yahoo.com> writes:
> > There was a lengthy discussion about this issue a
> > couple of months back. It was decided that the
> > implementer of the functionality would get to name
> it.
>
> I don't remember the exact discussion, but I hope we
> were a little
> more cooperative than that :-). Maybe someone said
> that jokingly or
> something.
>
> I think what was really meant was, let's not spend
> energy worrying
> about it until it's implemented, since it's not
> trivial to do and
> isn't likely to happen immediately.
When I first wrote the above, I knew it didn't sound
quite right. I should've put such a disclaimer with
it. Thanks for putting more appropriately.
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame game (svn cat (was: Re: svn up -p)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> There was a lengthy discussion about this issue a
> couple of months back. It was decided that the
> implementer of the functionality would get to name it.
I don't remember the exact discussion, but I hope we were a little
more cooperative than that :-). Maybe someone said that jokingly or
something.
I think what was really meant was, let's not spend energy worrying
about it until it's implemented, since it's not trivial to do and
isn't likely to happen immediately.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn blame game (svn cat (was: Re: svn up -p)
Posted by Noel Yap <ya...@yahoo.com>.
--- Barry Scott <ba...@ntlworld.com> wrote:
> I keep seeing the "blame" command being talked
> about. That
> is a terrible name for a command. In many
> organisations its
> seen as bad practice to "blame" developers for bugs.
> I'd have
> chosen a command name like "annotate".
There was a lengthy discussion about this issue a
couple of months back. It was decided that the
implementer of the functionality would get to name it.
Maybe the issue can be put to rest if "cat -v" were
used instead.
Noel
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn cat (was: Re: svn up -p)
Posted by Barry Scott <ba...@ntlworld.com>.
I keep seeing the "blame" command being talked about. That
is a terrible name for a command. In many organisations its
seen as bad practice to "blame" developers for bugs. I'd have
chosen a command name like "annotate".
Barry
> -----Original Message-----
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: 06 November 2002 19:59
> To: dev@subversion.tigris.org
> Subject: Re: svn cat (was: Re: svn up -p)
>
>
> Benjamin Pflugmann wrote:
>
> >Hello.
> >
> >On Wed 2002-11-06 at 04:28:22 -0800, Noel Yap wrote:
> >[...]
> >
> >
> >>Another thought that's flashed through my mind is that
> >>the soon-to-come "blame" is very similar to this
> >>functionality.
> >>
> >>
> >
> >Funny. While reading the thread, I just came up with the
> >same idea. So, I second that.
> >
> These are very strange and disturbing associations.
>
> "cat" would fetch a file and pipe it to the standard output. "blame"
> would print a line-by-line annotation, but only for text files. I fail
> to see how those are even remotely similar, except in that they write
> something to stdout.
>
> --
> Brane Cibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn cat (was: Re: svn up -p)
Posted by Branko Čibej <br...@xbc.nu>.
Benjamin Pflugmann wrote:
>Hello.
>
>On Wed 2002-11-06 at 04:28:22 -0800, Noel Yap wrote:
>[...]
>
>
>>Another thought that's flashed through my mind is that
>>the soon-to-come "blame" is very similar to this
>>functionality.
>>
>>
>
>Funny. While reading the thread, I just came up with the
>same idea. So, I second that.
>
These are very strange and disturbing associations.
"cat" would fetch a file and pipe it to the standard output. "blame"
would print a line-by-line annotation, but only for text files. I fail
to see how those are even remotely similar, except in that they write
something to stdout.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org