Mats,
I believe Parabuild handles this situation gracefully for
Subversion. It keeps track of change list numbers for every
build and doesn't require labeling at all.
--AlexP
--- Mats Sigge <mats@sigge.cc> wrote:
> Hello. My company is currently using Serena ChangeMan (i.e. PVCS) but we're
> not very happy with it and are probably moving to Subversion. But we'd like
> to know if it's possible to (sort of) keep working as we have regarding
> builds.
>
>
>
> Instead of building the very latest from the trunk, we use a label (or tag
> if you wish) called "build". When we build our product, we check out ("get")
> everything labelled "build" and build from that (and of course we also
> create a label for the current build, so we can recreate it later). And when
> checking in code, normally a file will be given the "build" label when it's
> checked in (i.e. the label is moved to the latest version), but on occasion,
> code is checked in without being labelled. Now, I can think of several
> reasons why this is bad (and personally, I don't really like it) but what it
> does give us is the ability to check in "(near) future" changes directly to
> the trunk without branching. I.e. if I know that I'm the only developer
> working on a file, and I'm fairly confident that it won't need other changes
> right now, I can check in stuff which shouldn't be included in builds until
> a few days ahead. Now, my question is: is this doable with Subversion? I
> can't think of a simple way of using Subversion tags for this (at the very
> least, we'd need a separate commit for updating the tag). Is it possible to
> use a property instead, i.e. each file contains a property saying which
> revision contains the "build version" of a that particular file?
>
>
>
> Of course I realize that one reason for this way of working is the lack of
> good merging support in PVCS, and with Subversion it's much easier (and more
> efficient I'd imagine) to create short-lived branches, so the need for this
> decreases. But it's always nice to at least know what your options are.
>
>
>
> Cheers,
>
>
>
> / Mats
>
>
>
> PS. I hope the above is at least slightly understandable.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 2 22:52:43 2005