active INN VCS repositories

[Ivan Shmakov]

>>>>> Russ Allbery <rra at stanford.edu> writes:

 >>> except for arch, which is almost unusable.

 >> I use Arch for my projects for about a year and a half.  While it
 >> was somewhat troublesome to learn, it, in my opinion, paid off by
 >> now.  It's somewhat OT, but could you explain what difficulties you
 >> see are there with GNU Arch?

 > I've used it for various things, but it's painfully slow,

	I guess, it's because it was decided to use external utilities
	(e. g., diff) to perform certain tasks.

 > it has the strangest command-line interface of any revision control
 > system that I've ever used,

	It also differs somewhat in the overall design.

	The concept of archive names, independent of archive locations,
	is in my opinion, generally a good thing, which most of the DVCS
	are currently lacking.  And surely, its implementation adds a
	bit to the complexety of the CLI.

	An other idea is that there's no ``default'' branch (like,
	e. g., CVS HEAD) and the archive may hold independent branches.
	Most of the other DVCS I've seen are primarily oriented on
	holding related branches in the repository.

	Furthermore, when creating a private branch, one may choose
	either to ``clone'' (``mirror'' in the terms of GNU Arch) the
	source repository, or its part, or the only revision which will
	became the `base-0' revision of the newly created branch.  I
	believe it's an advantage of GNU Arch.  I haven't seen an
	analogous feature in either Git or Bzr (though I'm aware of the
	shallow branches feature in Git.)

 > and common operations are either not present or require bizarre
 > contortions (like a simple revert of a mistaken change).

	Reverting an uncommited change was as simple as $ tla undo.  To
	revert a specific committed change I'd use, e. g.:

$ tla replay --reverse [ARCHIVE/]VERSION--patch-NUMBER

	Of course, one should not remove the changes /from/ the
	repository.

 > It doesn't even generate nice log output, or at least I don't know
 > the magic incantation to make it do so.

	Depending on the purpose, I'd use either $ tla revisions -scDf
	(--summary, --creator, --date, --full), or $ tla changelog.

	When I need to examine the changes in the remote repository, I'd
	use $ tla missing -scDf to see the log entries just for the
	changes not already reflected in the working copy.

 > It doesn't work like a regular revision control system.

	Yes.  I believe its aim was not to provide a distributed
	counterpart to CVS, but to enhance the very developer's
	workflow.  Being distributed is, thus, more a mean, not an end.

 > I've used bzr much more extensively, and it's way easier to use, but
 > I've not really used it in the distributed mode since I haven't had a
 > specific need and I haven't had time to sit down and play with it.
 > Which means I've mostly used it like I'd use Subversion, which is
 > rather boring.

	Most of my need in a DVCS was due to my desire to be able to
	work on some projects both at home (with no permanent Internet
	connection) and at work.  To this end, I've set up a couple of
	GNU Arch archives to commit the changes to, and used
	`star-merge' to copy the changes from one to another.

	I've used GNU Arch to track some ``third party'' source packages
	as well, mostly to use its (inherent to the DVCS design) ability
	to track the list of changes already merged into the branch.

[...]

 >>> I still don't personally know git.  It's on my list to learn, but
 >>> as you can tell from my lack of activity on INN, I have almost no
 >>> free time to pursue things like that.

 >> It took very little time for me to learn the basics of Git,
 >> Mercurial and Bzr, although I've been using Arch for more than a
 >> year by that time, so the basic concepts of DVCS (and I deem them to
 >> be quite hard to get in) were already known to me.

 > I know enough git to clone a remote repository and submit patches,

	So am I.  I'm a bit more familiar with Mercurial and Bzr.

 > but to really use it for a project that I was running would require a
 > lot more than that, and yes, the DVCS workflow is a large part of
 > that.  I suppose I'd be in a better place with that if I fought
 > through learning arch, but I'm hoping the field has matured a lot
 > since then.

	Surely, the tools in use nowadays are faster, more robust, and,
	in many respects, more convenient.  However, I still miss some
	of the features of Arch.

 > I need to understand the branching model, pulling remote
 > repositories, when to use rebase, and that sort of thing.

	ACK.

 > But anyway, our use of Subversion doesn't stop you!  That's why we
 > provide a read-only Subversion repository.  Point git-svn at it and
 > you can do just about anything you'd be able to do if we were using
 > git except have us pull a remote repository, and I don't think that's
 > a huge loss.

	Indeed, that's what I'm going to do.  I guess, the use of
	`git-svn' doesn't put too much load on the server?

	My interest in (D)VCS isn't limited to the INN project.  I'm
	somewhat interested in the VCS'es themselves and, in particular,
	in the opinions on the advantages and the disadvantages of using
	a particular VCS.