Re: [MinGW-dvlpr] Weirdness with issue.log

[Keith M. <kei...@us...>]

On 02/05/11 02:05, Charles Wilson wrote:
> On 5/1/2011 6:11 PM, Keith Marshall wrote:
>> ...
>> 
>> [*] This still retains an "all-sync-to-cvs" as a prerequisite to the
>> "all" goal.  I'm considering removing that too; although it will place
>> the onus on each of us, individually, to ensure that our respective
>> issue.log files are kept in sync, 
> 
> What do you mean?  Something like:
> 
> 	1) cvs update
> 	2) make
> 	3) cvs commit quick-like-a-bunny before somebody else beats you to it.

Yep.

> I realize we have a similar race condition now, so it's probably a moot
> point.

Ack.

>> it could offer benefits:
>>
>> ...
>> 
>> 2) No imposed sync; we each update when it is most convenient to our own
>> work flow, (just as we would for any other package).
> 
> Err...not really.  Because you have a "build product" -- the issue.log
> -- checked in to VCS, there is an issue with merging when private
> checkouts diverge.   That is, if you and I check out 'bash' and both
> modify var_match.c, we'll have the typical merge issue on that *source
> file* depending on who checks their mods in first.
> 
> But...issue.log is not a "source file" -- it's an output file.  So...
> 'cvs commit' is going to be awkward, even if you are updating
> msys-foo.xml and I am updating msys-bar.xml, because we'll have a merge
> issue with issue.log.  Or am I missing something?

Yeah, you could hit a merge conflict on commit, but is that really any
different from two developers independently modifying the same hunk of
any regular VCS tracked source file, in incompatible ways?  Even though
issue.log is automatically generated, the conflict should arise only if
two of us independently modify the same manifest source within a common
commit window, because only in that scenario are we affecting the same
line entry in issue.log.

>> Thoughts?
> 
> 1) Why sha1, which adds the requirement that openssl be installed --
> when md5sum is part of msys-coreutils?  (Now, granted, since we're
> dealing with authenticated cvs via :ext: with CVS_RSH=ssh...we all HAVE
> to have openssh installed, which means we DO have openssl installed, so
> I guess it doesn't REALLY add a new dependency)

SHA1 has a greater bit length than MD5, so better granularity; not
really a big deal, I know, but it does reduce the (admittedly slight)
probability of a hash collision.

Piping the awk output through `openssl sha1', (or even `openssl md5',
for that matter), yields the hash in a cleaner, and more useable format
than either sha1hash or md5sum.  Again, not a big deal, but it does save
an extra round of filtering, to strip away the cruft.

> 2) If it works, then I'm fine with the new implementation.  If you want
> to remove the all-sync-to-cvs rule, I think that should be delayed --
> due to the "one major change at a time" rule. Which I just made up.

Well, it's not a bad rule to adopt, anyway.  However, I've already
removed the `all-sync-offline' rule, (because the new build method
supplants it), and since the primary motivation for `all-sync-to-cvs'
was to synchronise time stamps, (which it didn't achieve effectively in
any case), it's now mostly redundant.  I can remove it now, or I can
remove it from 1.1 -- it makes little difference to me either way.

-- 
Regards,
Keith.