Re: utf8 patch for mc, slang 2 version
- From: Pavel Roskin <proski gnu org>
- To: Jindrich Novy <jnovy redhat com>
- Cc: MC development <mc-devel gnome org>, Leonard den Ottolander <leonard den ottolander nl>
- Subject: Re: utf8 patch for mc, slang 2 version
- Date: Mon, 12 Jun 2006 18:08:02 -0400
Hello!
On Mon, 2006-06-12 at 10:55 +0200, Jindrich Novy wrote:
> The problem is that Vladimir and me use different versions of mc. My
> approach is to be more in sync with upstream so that there's a more
> recent CVS snapshot in Fedora for now because of a very rare release
> period of mc. This helps me to do only minimal changes when I want to
> send a patch to upstream. SuSE uses the stable mc-4.6.1, AFAIK.
>
> +1 for storing useful patches in contrib. It would be quite hard to keep
> them in sync with devel mc though.
When I see a proposal to store any patches under version control, it
makes me think that the version control system is inadequate. The
natural representation of patches is differences between file revisions
under version control.
I think CVS it too centralized for the decentralized development that is
done on mc. It's not possible for a non-committing user to create a
separate branch.
Recent years gave us several decentralized version control systems, such
as Arch, BitKeeper, Monotone, Git and Mercurial. Their common feature
is that every user has the complete repository of the project. Changes
are exchanged between repositories in the form of changesets, either by
e-mail or using other protocols. Branching is more advanced, merging is
easier, and the merge history is recorded.
Most importantly, branching is local. It should be possible to use an
old version as the base and then rebase the patches while keeping track
of what was actually merged.
I think Git would be a great choice because it's free, actively
developed and used by major projects such as Linux kernel and Wine. It
also has a frontend called StGIT, which allows refining patches before
submitting them to other developers.
Git repositories work over http. Perhaps ibiblio.com would be persuaded
to host the main repository.
--
Regards,
Pavel Roskin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]