Re: [boost] [polygon] 1.44 release?

Subject: Re: [boost] [polygon] 1.44 release?
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-06-21 19:23:39

Thomas Klimpel wrote:
> Simonson, Lucanus wrote:
>>>> I just checked in fixes for all the inspect errors that were left
>>>> in the docs.  Is it OK or me to merge to release branch? [snip]
>> 
>> I have checked boost/polygon and libs/polygon into the release
>> branch. 
> 
> Why did you "checkin" instead of "merge"? You had asked for
> permission to "merge", not for permission to do an "initial checkin".
> I'm not subversion expert enough to know whether this will cause
> trouble for the merge tracking or not, but I don't understand why you
> preferred an "initial checkin" over the recommended "merge".    

Because I am used to using add and commit and less used to using merge.  I am not an SVN expert either.  I followed the same procedure as when I "merged" from the sandbox to the trunk, which was to copy the directory structure over, add it to the trunk and then commit the new files.  There may be metadata that would have been created by a merge command that is absent, as you suggest.  There may be more potential for a botched checkin of partial copy than a botched merge because I am manually doing some extra steps that the tool might do for me.  Indeed, the images and sample code for my Mikowski sum of polygon sets tutorial were somehow missing from the release branch and I have just added them in the release branch.  I don't know why that happened and I can't say for sure whether I would have had the same problem merging as copying.

I'm used to working in a different revision control system for every different project I am involved in and tend to get by using the minimal and sufficient set of features provided by the revision control system to get the job done since becoming a power user of N different systems is at cross purposes with getting any work done.  I've worked on projects where all of the meta data for all files was corrupted and there was effectively no way to tell who checked in what and when or from where.  Since file ownership was clear, the team small and communication and testing generally good this didn't pose much problem.  In another project we extensivly tracked and managed branches for each and every of thousands of source files in great detail, the project was large, the build was brittle and knowing who checked in what and when, from where and for which release was a full time job for one out of ten developers of the hundreds involved.  If dependencies are established on my library by other boost libraries I imagine that knowing which revision number of the trunk was merged to the release branch could become important.

Thanks,
Luke