That would do exactly what I want. Only while at it, I'd make the syntax
slightly more elaborate, such that you can set background and forground
color. Just because sometimes if you really need something to stick out,
background works better and because if something like that is done for
the foreground, then its probably only a few more lines of code to get
it for the background as well. (I imagine, in absence of any knowlegde
of TSVN internals)
Seb
-----Original Message-----
From: news [mailto:news@sea.gmane.org]On Behalf Of Mark Clements
Sent: Friday, 22 September 2006 10:13
To: users@tortoisesvn.tigris.org
Subject: Re: Feature Request: Colored log
"Simon Large" <simon@skirridsystems.co.uk>
wrote in message news:451308A0.4030707@skirridsystems.co.uk...
> SebastianUnger@eaton.com wrote:
> > Regex' don't do the job, that I had in mind, as the scripts actually
> > have to change the colour of a line, once that rev has been build.
> >
> > As far as speed goes, don't you already have to talk to the server
to
> > get the log property? I know nothing about the internals of SVN
server
> > comms, but I would have hoped, that you can in the same round trip
get
> > any and all properties you need.
>
> No. The call we use is equivalent to svn log -v, which gets log
message
> and author, changed files, etc in a single call. You would need a
> separate call (svn propget --revprop -rN) for *each* revision to pick
up
> a specific rev-prop.
>
> > Also, I guess, if you made the feature
> > optional, then the danger of people chasing you would be reduced and
> > even if they track you down, you would always have the defence of
"Well
> > YOU turned it on, didn't you?!"
>
> You mean there's a way to stop people reading the revprops?
>
> > I know it's very much a nice to have feature, but for us it would
be,
> > well, nice to have. ;-)
>
> The only way this could work efficiently would be for your program to
> add a line to the revision's log message, which is a bit risky. In
that
> case you could use some sort of coding like that which is used for
> *bold* and _underline_, or use a regex to pick out special information
> in the same way we do for bugtraq properties. This could also be used
> for colour coding revisions according to whether they are bugfixes,
new
> features, cleanup, etc. But it all sounds like a lot of work.
I was imagining a _global_ property which contained regex and color
combinations, e.g.:
/merge/#00FF00
/bug:?\s[0-9]+/#0000FF
/.*branch.*/#FF0000
Which would be used by the client to colour the word 'merge' green,
highlight any bug numbers in blue and mark the whole of a branch log
message
in red. Obviously the regex could be better, but they serve as
examples.
Precedence would be in the order of declaration, so in the above example
a
message that contained the word 'merge' and the word 'branch' would end
up
red, whereas if you swapped these rounds you would get a red message
with
'merge' in green.
Whether this is a property that is set on the server or by the client is
an
implementation detail (to me it make most sense as a client
setting).Would
this not do what you want, or am I missing something?
- Mark Clements
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Sep 22 00:31:15 2006