That's pretty much the idea, except that what you really want is to
be able to get the rev# implied by a tag, which can be done with some
even more ugly shell hacking. The downside of course is this is
platform dependent and very much a second-class citizen.
--Tim
On Nov 14, 2006, at 3:45 PM, Dmitri Colebatch wrote:
> Hi Tim et al,
>
> On 11/15/06, Tim Hill <drtimhill@comcast.net> wrote:
> Revision properties could fulfill much of this need, but the
> implementation of these is (imho) broken, since they cannot be set
> atomically as part of a commit (which, btw, would also make them far
> less dangerous).
>
> I'm a relative newbie to svn but had wondered about this approach.
> Has anyone done any work on this? Whilst just about all of svn is
> convention rather than rule, adding a property to a bunch of files
> seems like a pretty good alternative. In addition to this, given
> that the revision numbers are for the entire repository all I'd
> need is one place in svn that "hacked in" the "tags". I had even
> thought of having one file that contained my tags... something like:
>
> svn://server/module/trunk
> svn://server/module/taginfo.txt
>
> I could then write a script that used a combination of svn info,
> some parsing of the output (is there a better way to simply get the
> current revision?), and svn commit. These three would then give me
> a taginfo.txt file that looked something like:
>
> [tagname]=[revision]
>
> When I want to export, I'd then have another script that did the
> reverse... something like:
>
> svn ex -r `svn cat svn://server/module/taginfo.txt | grep
> [tagname]` svn://server/module/trunk
>
> Having given this all of 5 minutes thought it seems like a fairly
> workable "convention". Of course native support would be better,
> but from what I gather that aint going to happen. Having said all
> this, I don't want to be doing something that other people think is
> a bad idea and so would appreciate feedback on this.
>
> cheers
> dim
Received on Wed Nov 15 01:03:02 2006