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

Re: Revision numbers to what degree are they permanent

From: Samay <getafix123_at_hotmail.com>
Date: 2005-10-27 04:21:51 CEST

----- Original Message -----
From: "Kahn, Peter" <Peter.Kahn@ironmountain.com>
To: <users@subversion.tigris.org>
Sent: Thursday, October 27, 2005 6:50 AM
Subject: Revision numbers to what degree are they permanent

>I am setting up another subversion environment and I thought I might use
> revision numbers as build numbers. It means that build numbers will
> ratchet
> up rather quickly in a non-contiguous manner, but that may be acceptable.
> If I use revision numbers as build numbers I need to know to what extent I
> can rely upon revision x always being revision x. The only case where I
> could envision a revision number's meaning shifting would be in an
> export/import or dump/load situation.
> - If I dump and load my repository, will my revision numbers be the same?
> Will r2030 still be r2030?
> - If I dump and partially reload will the revisions be renumbered giving
> the
> new starting point?
> Thanks for the help....
> --
> Peter Kahn
> peter.kahn@ironmountain.com
> Iron Mountain Digital
> IM: pkahn@imserver, citizenkahn@jabber80.com, citizenkahn@googletalk.com

Whilst Rev Numbers should remain stagnant unless specific set of options are
used alogn with "svnadmin load" command, however, in case where one is
required to use those specific options (e.g. a corruption in repo?) in that
case one may not be able to match some build number against revision
numbers. This IMO, is a substantial risk and just relying on revision
numbers alone is not sufficient.

As a mitigation strategy against it, my suggestion has been to put the
revision ID and/or BUILD ID in the Log message as well. so that if revision
numbers are ever renumbered/reorganised, one can still search the log
message and checkout that specific code. Its not a fool proof strategy, but
cant think of something better! have you any better solutions or approaches
do suggest as it is a legitimate concern.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 27 04:24:14 2005

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.