Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 09:17:20AM +0200, Andreas Metzler wrote:
> On 2004-09-04 Colin Watson <cjwatson@debian.org> wrote:
> > I recommend using a good revision control system instead, which offers
> > similar benefits to developers while leaving things clear for users.
>
> I disagree that this is so clear-cut. The still most popular system
> CVS simply does not offer this functionality. e.g. you have two
> distinct patchsets: patchset A fixing issue A touching files 1, 2,
> and 3 and patchset B fixing issue B touching files 2, 3 and 4.
>
> CVS simply does not offer the possibility to keep these patchsets
> separate (except for checking in diff-files.) over several generations
> of a file.
CVS clearly doesn't count as a good revision control system (any more,
at least).
> I doubt svn favours a lot better in this respect (otherwise why would
> xfree-packaging still use a dpatch-like system?)
Subversion at least has changesets, so it's not anywhere near as bad. It
doesn't have proper merge tracking yet. This is not necessarily a big
problem if you don't have too many branches of the repository.
I don't think "xfree86 still uses separated patches" implies that
Subversion can't do what you want here; it implies that the xfree86
maintainers didn't want to overhaul their build system too much when
they moved to Subversion and have had better things to do since, but
that's about it.
I believe xfree86's build system is derived from an early version of
DBS.
> Bitkeeper can do it, and I guess arch, too.
Arch can, yes.
> If you are thinking "use separate .diff files in your repository but
> upload a plain diff.gz with everything mangled together" I disagree.
> I'd rather have slightly more complicated but usable sourcepackages in
> the archive.
I don't mind if there's also a debian/patches/ directory in the source
package (yes, I know that would double the size of the diff, but I don't
think that's important), but I think it should be a requirement that
'dpkg-source -x foo.dsc' should produce the code that is built.
(I don't expect this requirement to start being fulfilled again in
Debian any time soon, but that doesn't stop me trying to stop the
situation getting worse.)
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: