> 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.
>
Hi,
I would like to point out that perforce also has global change numbers.
In many ways its a requirement of having atomic commits - without global
change #s, you'd need 2 pieces of data: which portion of the repo and
the change #.
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. 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.
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, so SVN is so far way up on CVS, but why stop
at replacing CVS? Why not provide a 'p4-lite-ish' tool? 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
?
Regards,
-ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 06:58:24 2003