> less trivial. It doesn't help that svn rev ids are global rather than
> sequentially allocated per development line -- so, after a few years,
> my corporate repository is presumably going to have 6-digit ids and so
> forth -- and good luck building a nice graphical map of the merge
> histories of my various project branches.
I would like to point out that perforce also has global change numbers.
In many ways its a requirement of having atomic commits
I'm not so sure about that. Suppose that your repository contains
multiple projects. You don't need to have numbers that totally order
the commits in all projects -- you only need numbers that order the
commits within each separate project.
- without global
change #s, you'd need 2 pieces of data: which portion of the repo and
the change #.
You effectively need that anyway. In svn's case, a path plus a rev id.
If change #s are sequentially allocated starting at 0 per project
(e.g. project path), that makes them easier to think about and type
and speak over the phone and manipulate in scripts (without server
roundtrips) and so forth. Consider the simple question of laying out
a report about the changes made to project foo (path /trunk/foo)
between @X and @Y: Do you need (1 + Y - X) rows? or do you need to
ask a server how many rows you need?
I work at a company with a large p4 repository. We're migrating from 1
repo to another right now, but the old p4 db has 5 digit change
numbers. I think we're cresting 250,000 soon.
Sure. I've heard of significantly larger-scale repositories, too.
And I don't think they'll even be all that rare -- e.g., repositories
for "complete GNU/Linux distributions".
I'm not the actual p4 admin, so I'm not sure if that is causing any
problems. I think the actual issue of dealing with SO many changes
is causing the problem, not the actual size of the change number.
I'm imagining things such as a phone conversation between two
programmers: "A: I merged that in 192158. B: [typing in background]
you said one nine two five one eight?"
As for your other comments, re: branch merging, I concur completely. We
have extremely complex merges, usually we integrate the mainline branch
to a release branch, work on that, integrate a few minor things from
mainline->release or release->mainline, and then a few weeks later we
start all over again. I imagine this is a fairly common scenario. CVS
can't remotely handle this,
Just as a point of trivia -- if you very carefully, wisely, and
patiently use use tags, CVS _can_ handle this -- just not very
gracefully or efficiently or with support for distribution.
so SVN is so far way up on CVS, but why stop at replacing CVS? Why
not provide a 'p4-lite-ish' tool?
What do you mean "lite"? :-)
For the sake of "full disclosure": on the arch-users list (I'm the
author of arch), we take it as axiomatic that svn is broken and
foolish and arch conquers all. Here on svn's dev list, I presume we
take it as axiomatic that svn is very useful.
In real life: while I have reservations about some of the
implementation choices of both systems, I find it interesting that the
good parts of each have only slightly overlapping features and that
the union of those feature sets adds up to something that leapfrogs
every other system I've heard of.
Something that is useful for
medium complexity project (50-150 developers?). To get there, I'd
say handling all the complex merges would be key.
As for your idea, very interesting, would you care to expand it greatly
?
It's really hard to compress into a brief email message especially
when my financial TTL is so short.
Join arch-users@fifthvision.net (poke around at arch.fifthvision.net
to find the detailed info about the list).
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 08:20:39 2003