tech-repository archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: video of git talk
Perry E. Metzger wrote:
David Holland <dholland-developers%netbsd.org@localhost> writes:
> On Sat, Jul 26, 2008 at 09:44:43PM +0200, Adam Hamsik wrote:
>> I think that write our own VCS is probably best option for us.
>
> I don't think it's a good option. But I've also concluded that if we
> want something better than CVS we're going to need to write it - all
> the existing alternatives have serious drawbacks.
>
> It is not a small undertaking, though.
Unfortunately, I don't see why we assume we could do better than all
the other attempts that have been made. A lot of smart people have
worked on this problem -- look at the proliferation of systems out
there now.
So, I now use:
sccs/teamware at work
hg (mercurial) at work
svn for freebsd
cvs for netbsd and at home
If you're going to use hg then you also need to have cadmium (cdm) but
even then it is pretty raw... much more so than any of the others. One of
the catches with hg, especially in an active commit environment, is that
you must have the latest things pull'd before it lets you do a push, even
if the newer changes do not touch the same files as you.
Both svn and hg suck in that you cannot get a single file or small
sub-directory tree out of a repo, you need to get the whole f'ing thing.
This isn't just a workflow thing of being able to checkout src/gnu,
but also, for example, being able to do 'cvs checkout sys/sys/param.h'.
The tools we use for teamware undoubtedly include a lot of local
customisations to make things better over NFS, and some of its
methods, while different, do have merit. For example, needing to
explicitly say i want to edit foo and it keeping a list of files that you
are working on rather than just seeing what's changed.
Each of the above tools solves a particular set of problems but
none of them is the perfect universal DVCS and none of the
alternatives seem to fit well into the netbsd way of life.
So while lots of smart and intelligent people may have worked on
this problem, I'm willing to bet that none of them have come up with
a design/product that was built from the ground up to serve this
project. Thus I think we, and the open source community, could be
well served if someone or some people sat down to design and write
such a tool that did do what we wanted.
Darren
Home |
Main Index |
Thread Index |
Old Index