Source browser

[Christoph Kappel]

Will there a source browser like the one in trac be too?
Would be great to see this feature. I have some experience in RoR - so
I will try to add a browser for Mercurial - my VCS by choice.

[Peter Jones]

This is a feature that I've gone back and forth with a few times now.
I think that a time line view is more important than a source browser.

For me, Devalot has been about communication. And a time line fits
nicely with that theme. A source code browser has benefit, but it's
also just as easy to download the code and review it with the tools
you are comfortable with.

Either way, Devalot needs an abstraction layer for version control
systems. I don't want to see it tied to a single system. I think
that's one of the downfalls for Trac.

--
Peter Jones
http://pmade.com

[Sam Lown]

I've used several systems in past that provide a source browser and I
can't honestly say I found them all that useful. Also, now that I'm
using Git for most of my projects now, the gitk tool is fantastic for
checking out the last set of changes and offers a far more
sophisticated view of the last set of merges.

That said, while I'm certainly not against a source browser, I agree
with Peter's comment that a time line is probably more important.

The TimelineEntry model I'd created to support the email messaging,
which is really just a proof of concept at the moment was designed to
be re-used to "timeline" anything.

Its just occurred to me in fact... an easy way for updating the
timeline from outside devalot, instead of complex polling, could be to
use a bit of REST on a timeline_entry controller and add update hooks
to the appropriate parts of the distribution system in use ...
hmmmm :-) Will think a bit more about that.

Cheers, sam

[Christoph Kappel]

A timeline is truly a thing that is very useful - especially for
communication - indeed. I like the the way of fixing bugs/tickets in
changesets and direct linking to the changeset. Trac uses some kind of
abstraction - it's not bound to subversion only. There are plugins for
almost all of the vcs out there.

We don't have to re-invent the wheel - on rubyforge are several
projects that provide an early stage of this layer. Maybe the projects
there are worth a view.

[Peter Jones]

Sam Lown wrote the following on Fri, Feb 08, 2008 at 10:56:39AM -0800:
> Its just occurred to me in fact... an easy way for updating the
> timeline from outside devalot, instead of complex polling, could be to
> use a bit of REST on a timeline_entry controller and add update hooks
> to the appropriate parts of the distribution system in use ...
> hmmmm :-) Will think a bit more about that.

Sam, I like where this is going. My only change would be that it's a
script in the Devalot script directory, and not on the controller.
With the controller, it would be too easy to forge time line events.

But, with a script, it could be easily added to a post-commit hook on
a revision control system. The script would bootstrap rails, and then
add the necessary records in the database.

The REST idea, although sexy, would be hard to secure. And it would
be lame to have a dedicated username and password for the revision
control system to use.

[Sam Lown]

> Sam, I like where this is going. My only change would be that it's a
> script in the Devalot script directory, and not on the controller.
> With the controller, it would be too easy to forge time line events.
>
> But, with a script, it could be easily added to a post-commit hook on
> a revision control system. The script would bootstrap rails, and then
> add the necessary records in the database.
>
> The REST idea, although sexy, would be hard to secure. And it would
> be lame to have a dedicated username and password for the revision
> control system to use.

Rather than username/password authentication, I was thinking more
along the lines of a project specific hash. A code that can be
generated by the administration users and copied into the version
control hooks configuration. I was also thinking along the line of
only allowing specific IPs.

While I agree a command based hook is the ideal solution security
wise, I can imagine situations where a repository may be stored on a
separate server and it could be really convenient to not depend on
everything being in one place. This is perhaps even more relevant with
distributed version control. Nonetheless, its mainly Model effort to
correctly parse the info allowing scripts or controllers to be created
easily.

Additionally, we could stick the patch information into the
TimelineEntry and provide a visual represent of the patch. This could
be very useful, especially for blaming people quickly :-)

Cheers, sam