[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Hierarchical SCM and CVS vs SVN vs arch (was Re: in-tre
[Gnu-arch-users] Hierarchical SCM and CVS vs SVN vs arch (was Re: in-tree pristines fatally ...)
Fri, 05 Dec 2003 09:13:44 +0000
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*
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
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).
BK/ClearCase/CVS/SVN/VSS/RCS/Perforce/etc: 0 (AFAIK)
Perhaps some [companies would reject arch because it is per-tree not
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
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."
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
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").
Tired of 56k? Get a FREE BT Broadband connection
- [Gnu-arch-users] Hierarchical SCM and CVS vs SVN vs arch (was Re: in-tree pristines fatally ...),
Misha Dorman <=