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

Re: Per module/file versioning

From: Talden <talden_at_gmail.com>
Date: 2007-09-19 01:42:44 CEST

The only way to get a revision per file per change would be to have
one repository per file. Revisions in Subversion are commits to the
repository not a to a file and do not work like CVS.

This is not generally an issue. You can still see the list of
revisions in which /Cobol/Prog1.COB changed by doing a log.

NB: I wouldn't consider CVS versioning as a solution 'for simplicity'
or, most often, 'for convenience' - if you use branching and merging
much then CVS revision numbers become meaningless.

On 9/19/07, Rudy Godoy Guillén <rudygodoyg@gmail.com> wrote:
> I have such an unusual case for versioning. I'm going to describe the use
> cases.
> We have a set of Cobol programs which, for simplicity and convenience are
> wanted to be versioned by file.
> For instance:
> /Cobol/Prog1.COB
> /Cobol/Prog2.COB
> and so on.
> The current procedure (manual), does increase by one the version each time
> that the file changes (ala VMS filesystem and CVS). I'm not able to
> replicate this under subversion since the versioning model is different.
> The other case is to be able to have an independent revision number for each
> module.
> So /root/projectA/ and /root/projectB/ have each their own set of versions.
> This is also something that cannot be done under Subversion, for what I
> understand. However I've been reading about svn:externals but I seem unable
> to not identify it's use on my case.
> Anyone has been on the same situation? There's another approach I can have
> to get the same goals (say that user knows that Prog1.COB:2 is the second
> version of Prog1.COB and Prog2.COB:5 is the 5th version of Prog2.COB ).
> thanks
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 19 01:43:01 2007

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.