[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Hi and a question

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2000-08-07 05:56:41 CEST

> Agreeing to most of the specification on a first read the, design
> rationale for making version numbers per-commit instead of per-file
> is not clear to me. I would appreciate if someone could give me a
> hint or a pointer to some reading on this one.

It makes it a lot easier to treat commits as atomic, and it's a
somewhat more natural viewpoint for a version control system which is
controlling a whole project rather than a bunch of files individually.

A better way to think about this is: why might you not want to make
version numbers per-commit? One answer is that per-commit version
numbers will be a lot bigger and thus harder to remember (I can look
at a CVS log and easily remember "I need the diff between 1.32 and
1.33 for this file", but "I need the diff for this file involved in
commit 43872" might require some cut and paste). The architects have
suggested that we might need to provide per-file versions as a
separate device to deal with this problem.
Received on Sat Oct 21 14:36:06 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.