[Gnu-arch-users] Hierarchical SCM and CVS vs SVN vs arch (was Re: in-tree pristines fatally ...)

[Misha Dorman]

Samuel wrote:
> It follows that businesses expect this same kind of support from their 
> source code management software.  What appeals to many businesses is that 
> CVS and SVN have a *single* repository, which *one* person is *responsible* 
> for maintaining.

I don't think it follows at all.

Many organisations have many projects with separate software development 
processes, and they have a repository for each (with each project being 
responsible for its own repo, often with support from a central SCM group). 
Many organisations have a (rather sensible) fear of relying on one person 
for anything so critical.

In any case, Arch (like BK) has the flexibility to support both centralised 
and distributed models effectively (modulo some group permissions foo which 
seems pretty easy to resolve).

You can do nice things like have per-developer repos (for speed, and to 
avoid clutter in the central repo, particularly when combined with archive 
cycling), star-merging/cherry-picking work into the central repo (or 
hierarchies of integration repos, for each team and for whole projects), AND 
nightly mirroring to server-held copies of each per-developer repo (e.g. to 
get backups "for free" via existing infrastructure).

Arch, BK: 1
ClearCase Multisite: 0.5
CVS/SVN/VSS/RCS/Perforce/etc: 0

> Then, when the repository maintainer needs to perform an integration, there 
> may be a
> module that (s)he doesn't want star-merged with something that (s)he does 
> want, which can lead to increased integration times, and woe is he, 
> additional work to weed out the changes (s)he doesn't want.

This is why we are (should be) careful to create independent atomic 
changesets (see prism merging, cherry picking and related techniques).

Contrary to the impression you gave, Arch actually gives the "repository 
maintainer" (more likely, a release branch maintainer) a lot more help in 
handling this case than CVS, SVN or most of the commercial tools (e.g. BK, 
AFAIK, doesn't directly support cherry-picking -- I think LM said that their 
repo push/pull transport protocol would be too slow if they had to check 
whether each individual changeset had been propagated).

Arch: 1
BK/ClearCase/CVS/SVN/VSS/RCS/Perforce/etc: 0 (AFAIK)

Tom wrote:
> Perhaps some [companies would reject arch because it is per-tree not 
> per-file].
> I doubt that that is _often_ the dominant consideration (even when its a
> handy excuse) and, anyway, it's not quite as meaningful a distinction as 
> you
> might think at first.

For some companies (or, more accurately, for some staff on some projects 
within some companies), the user's primary task is to update a single 
document/file (e.g. a graphic designer updating an icon on a software 
project, or a project manager updating a project plan) without reference to 
or dependencies on the other files in the project.

These users just want to get a copy of the relevant file (from the 
appropriate branch), update it, and commit the changes. Although they could 
get the whole project, they don't really want to, and the extra files will 
(a) take some time to get and commit (b) take some space and (c) confuse 
them (these are often the less OS-savvy users on the project). inode and 
hardlink hacks significantly reduce the impact of (a) and (b) but (c) is 
rather harder to solve.

One option is to use configs to separate out these files (e.g. keep all the 
art assets separately so that the artists don't need to check out the whole 
project). AFAIK, using configs forces those assets to be in separate 
directories from the source code, which may conflict with certain (lame but 
common) build tools.

Another idea would be a "get --files" with corresponding "commit --files". 
It would be nice if you could "get --files" (perhaps several times) and then 
have commit automatically do "commit --files" for those files that have 
actually been got (if you see what I mean). This would make arch as simple 
to use as RCS/SCCS/VSS for those single-file cases.

Any other ideas on how to address such users' needs as simply as possible 
(both in terms of the UI they see, and the amount of change to/scripting 
around arch needed to support it)?

Samuel's friend said:
> "[arch, like CVS] lacks SVN's ability to easily revert a [single] file to 
> an older revision."
Tom replied:
> Your friend was simply mistaken.

Could you both elaborate, for the record, as much as anything:
Mistaken that SVN has such an ability?
Mistaken CVS lacks it? [does cvs get -p abc.c > abc.c count as "easy 
ability"?]
Mistaken that arch lacks it? [tla file-find is the get -p equivalent, IIRC]
Or a combination of the above?

Has (Momchil's? Dustin's?) tla revert been added to tla1.1?

What are the advantages/disadvantages of tla revert compared with tla 
file-find abc.c > abc.c (apart from obvious [script-fixable] usability 
issues like having to give the filename twice)? (e.g. performance and 
applicability, both in presence/absence of revlibs/pristines, for both 
"revert to checked out" and "revert to arbitrary prior version").

Cheers
--
Misha Dorman

_________________________________________________________________
Tired of 56k? Get a FREE BT Broadband connection 
http://www.msn.co.uk/specials/btbroadband