[m-rev.] [reuse] synchronize reuse branch with main branch
Nancy Mazur
Nancy.Mazur at cs.kuleuven.ac.be
Thu Sep 12 16:14:48 AEST 2002
> > It seems that when checking in files from the reuse-branch, it looks at
> > the .nocopyright file from the main trunk. I've temporarely added
> > BCC_MAKEFILE to the main trunk .nocopyright file, which enables me to
> > check my reuse-branch version in without any problems.
> >
> > But I wonder, it cannot be the purpose for me updating .nocopyright on
> > the main trunk? Haven't other developers encountered that problem when
> > synchronizing their branch? I mean, CVS should have complained during
> > the first check-in of those files, anywhere in CVS?
>
> As far as I know this is a known limitation of check.pl (I wrote the
> code to check for .nocopyright)
>
> } elsif (open NOCOPYRIGHT,
> "co -q -p $directory/.nocopyright |") {
>
> This is the line that causes the problem -- if you know what the version
> number is of the .nocopyright you wish to checkout, you could pretty
> easily modify this line.
>
> However, when doing client-server CVS you only have access to files that
> are being checked in. So unless you changed .nocopyright in this
> checkin, you won't even have access to the .nocopyright file.
>
> I don't see how you can find out what version number the file is in this
> case.
>
> Perhaps we could try to figure out what branch the other files are on
> and get the latest version on that branch... Sounds tricky...
That would be a possibility...
but still, the .nocopyright file may as well contain a superset of all
the files of all the branches that don't have a copyright message, it's
perhaps not worth the fuss...
but
1. perhaps this should be documented somewhere? Maybe it is somewhere
already?
2. perhaps the check should also be done on new added files, on imported
files,... because what I understood is that Fergus was saying that the
check might not be performed in these cases, which means that
nobody thinks of updating the .nocopyright file at that moment, and
which therefore leaves other developers puzzled why the error only
occurred when they are updating something?
Ciao ciao,
Nancy
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list