You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Will Parsons <ou...@nodomain.invalid> on 2006/04/12 01:21:59 UTC

Assigning version ID's to individual file revisions

I am investigating moving our existing revision control system, which is
based on RCS, to subversion, but am having trouble seeing how to implement
assigning our own revision ID's to files as they are revised.  Under RCS,
we do this by assigning a tag, so that when a new version of file foo.c is
checked in, it receives a tag such as FOO_C-00-03, and this tag is used to
uniquely refer it.  The subversion concept of tags as branches doesn't seem
to lend itself to this.  If I understand correctly, each time a file is 
revised, a copy would have to be made of that file only to a new location in
the repository.  This seems to be very awkward for this purpose.

I have also looked at using properties for this purpose, but since there
doesn't seem to be a way of extracting the revision of a file whose
property x = y, this doesn't look like it will work either.

Can anyone suggest how to go about doing this?

- Will



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Assigning version ID's to individual file revisions

Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 4/11/2006 9:21 PM, Will Parsons wrote:
> I am investigating moving our existing revision control system, which is
> based on RCS, to subversion, but am having trouble seeing how to implement
> assigning our own revision ID's to files as they are revised.  Under RCS,
> we do this by assigning a tag, so that when a new version of file foo.c is
> checked in, it receives a tag such as FOO_C-00-03, and this tag is used to
> uniquely refer it.  The subversion concept of tags as branches doesn't seem
> to lend itself to this.  If I understand correctly, each time a file is 
> revised, a copy would have to be made of that file only to a new location in
> the repository.  This seems to be very awkward for this purpose.

The subversion idea of a tag is that it is a snapshot of the whole 
project at a particular point in time.  You want a snapshot of a 
particular file.

The revision number of the repository at the time the file is checked in 
seems to be what you want.  For example, if you make a revision, then 
check in foo.c, the repository revision will change to 12345; you can 
uniquely refer to that version as "/path/to/foo.c at r12345".

If you want to give a symbolic name to the 12345, you'll need to put 
together your own scheme to do so; Subversion doesn't support that.

> I have also looked at using properties for this purpose, but since there
> doesn't seem to be a way of extracting the revision of a file whose
> property x = y, this doesn't look like it will work either.
> 
> Can anyone suggest how to go about doing this?

Either change your practice so you refer to paths and revision numbers 
of files, or develop a simple scheme to store triplets of (symbolic 
name, path, revnumber) and make it available to your developers.

Duncan Murdoch

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Assigning version ID's to individual file revisions

Posted by William Nagel <bi...@stagelogic.com>.
On Apr 11, 2006, at 9:21 PM, Will Parsons wrote:

> I am investigating moving our existing revision control system,  
> which is
> based on RCS, to subversion, but am having trouble seeing how to  
> implement
> assigning our own revision ID's to files as they are revised.   
> Under RCS,
> we do this by assigning a tag, so that when a new version of file  
> foo.c is
> checked in, it receives a tag such as FOO_C-00-03, and this tag is  
> used to
> uniquely refer it.  The subversion concept of tags as branches  
> doesn't seem
> to lend itself to this.  If I understand correctly, each time a  
> file is
> revised, a copy would have to be made of that file only to a new  
> location in
> the repository.  This seems to be very awkward for this purpose.
>
> I have also looked at using properties for this purpose, but since  
> there
> doesn't seem to be a way of extracting the revision of a file whose
> property x = y, this doesn't look like it will work either.
>
> Can anyone suggest how to go about doing this?

You aren't the first person to ask about this.  There have actually  
been many long discussions on this mailing list about just this  
topic.  Currently Subversion doesn't support exactly what you want.   
If you'd like to know more, I suggest you search the mailing list for  
"labels".  That should dig up some of the longer discussion threads.

-Bill

>
> - Will
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Assigning version ID's to individual file revisions

Posted by "brinkleybw@bigfoot.com" <br...@gmail.com>.
Will,

I've been (mostly) lurking on this group for some time, but I've read enough
to know that this group has addressed the "Subversion doesn't do labels"
topic on many occassions.  Before I see another "Subversion is different --
just adapt" response, I figured I'd throw in my two cents and steer the
conversation down a different road.  I don't have a technical answer to your
question, but as a Configuration Management practitioner, I can suggest a
different approach to the situation.

When I migrate code from one tool to another, I pay attention only to
baseline releases; all of the intermediate files drop out of the equation
and the version numbers of each file become of secondary importance in
relation to the identified releases.  This is something that Subversion will
support, even if it isn't in quite the same way as the other tools.  Export
releases based on your RCS tags into the working area, check in the files,
and tag as a release; iterate through all releases of each app using this
approach.

If your shop doesn't really work from baselines (what I call
"latest-and-greatest release management" or "stream-of-consciousness
programming") another option is to migrate only the "leaves" of the project
tree (equivalent to the "latest baseline") and to keep a read-only copy of
the RCS files around for lookup.

Sometimes, adopting a new tool requires a major (warning: highly over-used
buzzword from the 1990s here) shift in paradigm.  IMHO, Subversion does a
nice job of removing you from the task managing file versions to the task of
managing releases.

Love to hear your thoughts on this.
-Brandon



On 4/11/06, Will Parsons <ou...@nodomain.invalid> wrote:
>
> I am investigating moving our existing revision control system, which is
> based on RCS, to subversion, but am having trouble seeing how to implement
> assigning our own revision ID's to files as they are revised.  Under RCS,
> we do this by assigning a tag, so that when a new version of file foo.c is
> checked in, it receives a tag such as FOO_C-00-03, and this tag is used to
> uniquely refer it.  The subversion concept of tags as branches doesn't
> seem
> to lend itself to this.  If I understand correctly, each time a file is
> revised, a copy would have to be made of that file only to a new location
> in
> the repository.  This seems to be very awkward for this purpose.
>
> I have also looked at using properties for this purpose, but since there
> doesn't seem to be a way of extracting the revision of a file whose
> property x = y, this doesn't look like it will work either.
>
> Can anyone suggest how to go about doing this?
>
> - Will
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>


--
-B