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

Re: Subversion vs CVS for document files

From: Talden <talden_at_gmail.com>
Date: 2006-11-15 01:27:40 CET

On Tue, 2006-11-14 at 13:33 -0800, Tim Hill wrote:
> > I guess it would help to understand the workflow better. You
> > mentioned talking over the phone and people who the document but do
> > not have access to svn or the repository. What is the intended usage
> > here? There is probably some form of tagging that will give you what
> > you want.

On 15/11/06, Les Mikesell <lesmikesell@gmail.com> wrote:
> I was thinking of the type of document that might be passed around
> and reviewed by a committee of people who don't have direct access
> to the repository and may or may not do any actual revisions to the
> text (returning it to someone to commit) but always need to know if
> the copy they are viewing is current.

CVS revisions don't work well here either.

The revision number is a bad measure of activity.

Consider what branching and merging do to revisions. Why aren't
branch commits accounted for in the main revision? Are merges really
changes or just absorbing a set of changes in a branch - shouldn't the
HEAD revision jump by the number of merged changes?.

Clearly the issue of the scale and depth of changes is also a very
important variable in measuring activity. The size and number of
diffs don't even give a reliable measure here. Is indenting a whole
file significant?

And by itself the revision number doesn't give any indication of how
current a file is, merely that it's more or less recent than a file
with a different number.

Best would be for a release mechanism to supply an electronically
signed release document which encloses electronic signatures for each
of the released documents. This way the release and its contents can
be authenticated.

I approach Subversion from an SCM perspective so I'm overjoyed at
subversions avoidance of two key bugbears (non-atomic commits breaking
concurrent updates and committers failing to observe changes prior to
commits).

Maybe Subversion is a square peg for a round hole... Or maybe the hole
being round isn't a real requirement.

I hope you find a solution that is suitable, but I don't think an SCM
is going to be the silver bullet by itself for the situation you're
describing.

NB: In case it hasn't been corrected - You don't have to get an entire
source-tree, you can pull down a single folder non-recursively. You
cannot practically get a single file though.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 01:28:22 2006

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

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