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

Re: Problems with Limitations or "Differences" of Subversion

From: Talden <talden_at_gmail.com>
Date: 2006-11-07 04:23:03 CET

On 11/7/06, Ryan Schmidt <subversion-2006d@ryandesign.com> wrote:
> On Nov 6, 2006, at 19:35, Eric wrote:
> > As we see it, the two main limitations of Subversion are the
> > inability to check out and check in individual files (you have to
> > do whole directories), and the fact that the version number for the
> > whole repository increments whenever you make any change to any one
> > file.
> >
> > I really can't defend the second issue .. it just seems to me like
> > a wrong design decision and I can't think of a reason why it's good
> > or why it happened.
> [snip]
> > If I make a change to the SRS, I don't want the SDD's version
> > number to bump.
> Do not think of it as the version number (or more properly: revision
> number) *of a file* or *of a directory* but instead *of the
> repository*. Attach no further meaning to this number other than "the
> number of changes that have been made to the repository." That's all
> it is.

I think it's more than that. Since, to discover the number of times
and when a given file/folder has been changed you list the revisions
in which it was changed. This means that revisions are relative to
one another and that they represent points in time (without explicitly
expressing time). That said, in a file-system where files are
inter-related, per-file revisions mean even less than the repository
revision in Subversion.

Not being able to follow a path forward through copies/moves
disappoints me (for that matter how cheap is listing revision numbers
for past changes) but I'm never going to worry that the revision
numbers representing when I did change a file aren't consecutive
values. I'd much rather know that two files were changed in the same
revision or that fileX changed after fileY (though preservation of
modification timestamps would ease this issue somewhat).

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 7 04:23:35 2006

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