[Dclug] Company wide deployment of version / source repository
Serge Wroclawski
serge at wroclawski.org
Mon May 5 06:58:31 EDT 2008
On Tue, Apr 29, 2008 at 09:30:37PM -0400, Larry Howe wrote:
> On Tue, 2008-04-29 at 10:54 -0700, Andre Lehovich wrote:
> > --- Serge Wroclawski <serge at wroclawski.org> wrote:
> > > > - revision graph: see how different files and codelines are related to
> > > > each other. From the graph you can call up info about each revision,
> > > > view the revision, etc.
> > >
> > > I'm not entirely sure what this means. Can you give an example?
> >
> > I interpreted it to mean the functionality provided by gitk, bzr viz, or hgk.
> >
> > --Andre
>
> Here are some examples:
>
> http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html
Thanks for the examples.
It seems that commit visualizations are pretty common in git. Gitthub,
a commercial git host, has a visualizer that looks quite similar:
http://github.com/blog/39-say-hello-to-the-network-graph-visualizer
But as Andre pointed out, there's gitk, which provides more
information about the repository in git in a more useful way. I think
the real answer though is that all VCSs can be coaxed into giving
visualizations but that on a day to day basis such visualizations
aren't necessary.
But back to my original point in the previous post, Perforce is a well
respected tool, I'm not going to knock it. Perforce is what Google
uses. It's (apparently) great for large organizations who have
thousands of people working on super-large repositories at the same
time. That was not the case with the original poster. It was a small
project I believe and if he didn't specify a number directly, I
believe it was under 30 people, none of which had done version control
before. In this case, the functionality provided by any of the version
control systems would do far more than he and his organization would
need for the foreseeable future.
Since I mentioned Google earlier and Google is very smart, two things
should be noted. First, Google is a special case. It's my
understanding that Google's perforce tree is unified. That means all
the projects are inside one big tree. Google is huge, with thousands
of developers working on various projects and code at the same time.
At the same time, it should be noted that Google adopted Perforce
before git was written, and that since git was written both Linus
Torvalds and Randal Schwartz have given talks about git at Google.
And again, I have a very strong Free Software bias, but more than
that, I have concerns when proprietary technology is put in an
essential role in an organization. If you were to say "We want to
install Flash on all the workstations." I'd probably shrug my
shoulders, but in the case of version control of source code- there
you're talking about putting a specific tool at the heart of all your
vital work processes and giving that tool control over your business's
crown jewels. In these cases you want to be extra cautious.
Anyway thanks for the pretty graph!
- Serge
More information about the Dclug
mailing list