Yann Dirson wrote:
>On Sat, Jan 18, 2003 at 03:23:05AM -0800, Josh MacDonald wrote:
>> > This reminds me of another thought I had. In my use of the branches,
>> > I mostly have 2 "super-branches", which I'd name "upstream" and
>> > "debian", of which real prcs branches would be child branches. This
>> > could be formalized in some useful way, eg. for graphing using the
>> > contrib tools, which draw in a different color in-branch checkins and
>> > cross-branch ones.
>> >
>> > My convention makes it possible to use prefixes in branch names as
>> > names for super-branches, but I guess it'd be too much DWIM to take
>> > this as always valid (even in my own repos). Then we would need a
>> > standard way to specify such super-to-subbranch information, probably
>> > in the prj file, but it seems it would need some work to maintain
>> > explicit relationships. Possibly the definition of a
>> > super-to-subbranch separator string would be enough (in examples below
>> > that would be "-").
>> >
>> > I originally thought this would not be the job of prcs proper to mess
>> > with that, but now I realize it would be nice to consider
>> > superbranches to be real prcs branches:
>> >
>> > # latest upstream version
>> > prcs checkout -r upstream
>> >
>> > # 3.2.2
>> > prcs checkout -r release-3-2-2
>> >
>> > # latest 3.2 release
>> > prcs checkout -r release-3-2
>> >
>> >
>> > Opinions ?
>>
>> I don't quite see what you are proposing. I liked Sam's comment and
>> agree with the way Lars does it.
>
>Let me explain in greater details.
>
>The way Lars works looks quite fine when you're maintaining the
>original source for a package. It can be applied in some cases to the
>packaging activity I described earlier in this thread, with something
>like:
>
>- one branch per "major" upstream version:
> upstream-3.2 -> upstream-3.2.1, upstream-3.2.2, etc
>
> This has the limitation that I usually don't have a grasp on the
> numbering scheme used by the upstream author, and some packages are
> numbered like "2.5a", or using dates, which would not cleanly fit
> here. It also does not fit releases named "x.y.0", which are quite
> often seen
>
> And even without those limitations, this would somehow force me to
> import *all* revision, if I want to keep those numbers in sync.
When tracking an external development independently with your own version
control system, you have no choice but to dissociate your local version
numbers from the program's version numbers:
PRCS version upstream-3.2 -> Program version 1.5
PRCS version upstream-3.3 -> Program version 1.5a
PRCS version upstream-3.4 -> Program version 1.6-sp3
You'll have to store the program version by some other means, in the PRCS
log messages, or by using a project keyword like VendorVersion. This of
course means that working with less-recent versions of the programs always
require looking up your local version number.
One way to simplify this is to add a file 'PRCS-HISTORY' to the archive and
list in there the relation between your local versions and the program
versions:
upstream-3.2 "1.5"
upstream-3.3 "1.5a"
upstream-3.4 "1.6-sp3"
By using a script for checking in new imported versions, maintenance of
this file can be automatic; and looking up older versions can be done with
grep (prcs checkout -r $(grep "1.6-sp3" PRCS-HISTORY | cut -d ' ' -f 1) ).
>For now I don't see another generic way to handle the problem, than
>creating a branch per upstream version, and one per debian version.
Yep.
>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.
>To get back to my super-branch idea, in this scheme, we could see
>"upstream" as a branch, whose successive revisions would be those of
>the successive upstream-* branches.
>
>The "problem" it's supposed to solve is that I find it a bit annoying,
>eg. when importing a new version, having to find the exact name for
>the branch I want to checkout the prj file from, when it's guaranted
>to be the most recent one starting with string "upstream".
You could solve this problem simply by calling the branch for the "most
recent" releases "upstream". Whenever the developers make a major version
shift, you can fork off an "upstream-v1" branch at the current point of
"upstream", and continue to use the "upstream" branch to track the v2
releases of the program.
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.
But if you use names as middle elements, it is no longer possible to
determine the "most recent" branch - you'd have to invent a naming scheme
like 'upstream.recent.*', and then you're no better off than with PRCS
current version naming ('upstream-recent.*').
--
Lars Duening; lars@xxxxxxxxxxx
GPG Key: http://www.bearnip.com/lars/lars-duening.gpgkey
|
