[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: preliminary version control requirements
David Holland <dholland-tech%netbsd.org@localhost> writes:
> On Sat, Jul 26, 2008 at 09:38:29PM -0400, Perry E. Metzger wrote:
> > > - doesn't require importing things we don't want into base
> > Not sure what that means.
> Well, as an extreme example, a version control system written in PHP
> would not be accepted.
Okay, granted. If you want to have that in a requirements list, I
suggest explaining it a bit more clearly, since I'm unlikely to be the
only person confused.
> > > - allows checkout without cloning entire history
> > I don't necessarily agree with the last bit there. It seems reasonably
> > arbitrary. There are systems that work very well but require local
> > copies of the repository. In a modern environment, where disk is quite
> > cheap, that seems fine to me. (And yes, you can mount a 500GB disk you
> > bought for $80 on your Vax over NFS.)
> Disk is not always cheap, and NFS mounting the source tree from
> somewhere where it is isn't always an option.
> I have a number of machines with source trees that don't have enough
> space for the full history, and I'm doubtless not alone.
What's the reason you can't NFS mount in those cases? (I don't
disbelieve you, I just want to understand better.)
> Of course, this depends to some extent on how big the full history is
> compared to the size of the checked out tree on its own. If it adds
> 10%, that's probably ok. If it triples the size, that's not.
Git is apparently famous for how well the compression works -- the X
people claim that the whole repo is a small multiple of the checkout
> > > - somehow preserves old file version numbers on import for reference
> > > - uses version numbers that are numbers, not hash codes
> > I'm not sure that is a critical requirement. Most modern systems don't
> > even have individual file version numbers anyway, they have repository
> > versions with atomic commits across the repo.
> Preserving the old version numbers is important because they're
> recorded all over everywhere (PRs, mailing lists, etc.) and losing the
> ability to correlate all those reports with the source tree would be a
I think there isn't a single VCS that will do that right now. If that
were really a requirement, we could never upgrade from CVS. I suspect
we're just going to have to manage old file version information by
keeping the CVS tree around for a while.
> Meanwhile, there are real reasons why hash codes are bad; they're hard
> for humans to use compared to small integers, and they're not ordered
> so you can't tell if the version you've got is newer or older than
> some version someone's posting about wihout digging around.
The lack of ordering is certainly a problem. The length might not be a
problem in practice -- git and the other systems that use them seem to
allow shortest unambiguous prefix, and that's generally only five or
> > > - supports rcsids/keyword expansion
> > Most of them don't per se do this, in that there aren't version
> > numbers for individual files in any modern system so there aren't
> > expandable RCSID equivalents with a file's individual version number.
> Why would it have to be a file's individual version number? It just
> has to indicate what stuff a binary file was built with. But we do
> need something that does that.
That particular requirement can be met. However, there is an implicit
requirement here that I want to mention is not going to be met.
> Most of the newer systems not only won't do rcsids but will explain to
> you at substantial length why they think you shouldn't want them, but
> that doesn't make them right.
> We could conceivably get rid of all the existing rcsid strings and
> arrange something that didn't require keyword expansion directly in
> files, but it would be a lot of work and a big hassle.
I wouldn't mind having to replace them across the whole tree with
different names, that would be fairly straightforward work. I agree
that having to set up a rube goldberg mechanism would be a big issue.
> > > - doesn't exhibit any excessively strange semantic excursions
> > I don't know what that means.
> Bizarre behavior. The first example that comes to mind is the way tags
> work in subversion.
Tags are just version numbers or (if you prefer) tree clones. Why is
I want to caution something overall here. I don't think we can achieve
"perfection". The set of everything you are asking for might be the
null set. We have to be careful not to overconstrain the problem.
Perry E. Metzger perry%piermont.com@localhost
Main Index |
Thread Index |