On Tue, Jan 28, 2003 at 12:22:13PM -0700, Lars Duening wrote:
> >Off-topic: In this scheme, I really like to have branch names
> >accurately reflect the real version: being able to use dots here is
> >great for this. But I find the concatenation of the branch name and
> >".revnumber" somewhat annoying there. Since they're quite distinct
> >things, I thought it could be possible to have a variant notation, but
> >that's not an idea I investigated much.
>
> A variant notation would do more harm than good, as it would introduce
> rather complicated evaluation rules for the version names. Working on the
> principle that branch names are not the actual version name is simpler in
> the long run.
What about, instead of refering to a given version in one branch using
one string made of those informations, simply use those 2 informations
as what they are: distinct informations ? That could be reflected by
using some space character as separator, for example:
# to get rev 4 of branch maint-1.1:
prcs checkout -r maint-1.1 4
# or:
prcs checkout -r "maint-1.1 4"
Aside from the syntax-incompatibility with current situation, this
could allow to omit the revision (as currently in "maint-1.1.@"), even
when there are dots in the branch name. After all, this constraint is
really artificial, and comes from the fact we force prcs to re-parse
something that would not need to be parsed.
But practically speaking, I can't see how to achieve that without
using another flag than "-r".
> But I think I finally understood your "super-branch" idea - though I'd call
> it "multi-level naming". So basically
>
> upstream.* -> tracks all releases from upstream
> upstream.@.* -> tracks the "most recent" releases
>
> with for example:
>
> upstream.3.4 -> Program version 1.6-sp3
> upstream.@.1 -> the first release of the latest version
>
> However there is a small problem: to meaningfully track the "most recent"
> releases, the middle version name elements would have to be numbers, which
> again leaves you with the problem of matching local with program versions.
Yes. This once again brings back the (human) need to be able to label
a revision with an arbitrarily-chose string (a tag).
Regards,
--
Yann Dirson <Yann.Dirson@xxxxxxxxxxxxx> http://www.alcove.com/
Technical support manager Responsable de l'assistance technique
Senior Free-Software Consultant Consultant senior en Logiciels Libres
Debian developer (dirson@xxxxxxxxxx) Développeur Debian
|
