[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 6430 - in trunk: . subversion/include

From: Paul L Lussier <pll_at_lanminds.com>
Date: 2003-07-10 21:39:05 CEST

In a message dated: Thu, 10 Jul 2003 20:05:50 BST
Philip Martin said:

>pll@lanminds.com writes:
>
>>>>>>> On Thu, 10 Jul 2003, "Philip" == Philip Martin wrote:
>>
>> Philip> r6394 is when the branch was made, so changes were committed
>> Philip> to the branch more recently than that. Is this intentional?
>>
>> I created the branch, then made changes to CHANGES, svn_version.h,
>> and committed those changes. At some point, these were ported back
>> to /trunk.
>>
>> Intentional? Ahm, not in a pre-meditated manner :) Chalk it up to a
>> learning curve? I don't quite know how to answer that question.
>>
>> Do you feel I did something incorrectly? If so, please explain, so I
>> can get it right for 25.1 :)
>
>It's not a big problem, but I think the branch point is the wrong
>revision to have in the CHANGES file, particularly if non-trivial
>changes are then made to the branch.

Hmmm. I see your point. Though, I would expect in general though,
that a release manager should probably not be making non-trivial
changes in a release branch. *I* certainly am not qualified to be
doing so :)

>> Philip> r6284 was the last change on the branch before it was tagged
>> Philip> (which means mprice had to guess the revision number in
>> Philip> advance!).
>>
>> I'm not sure how to respond to this. Are you saying I should have
>> done it's mprice's way, or that he was taking a change by guessing?
>> I'm unclear as to what your concerns are. Can you explain a little
>> more please?
>
>I don't really know what the correct procedure is--I've never made a
>release!

Wanna learn? I can show you ;)

>Guessing the revision is a bit of a hack, although it does produce a
>neat result if it works (and it will usually work as the repository is
>not that busy, on the odd occasion when it doesn't you can always try
>again). If you don't want to guess then you could use a placeholder,
>xxxx say, when committing the CHANGES file. Then do a final commit on
>the branch that only changes the placeholder. That way it would only
>be "trivially" out of date.

Hmmm. okay. I'll try to keep that in mind for next time.

Thanks,

-- 
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE
	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.
	 If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 10 21:40:08 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.