Re: Personal CVS repository?

[Steve deRosier]

In her place, what I would do is:
1. Keep two local workspaces.  One is the checkout from the remote repository, the other 
is the checkout from the local "personal" repository.
2. Do all my work in the local one, checking in as necessary.
3. When I "release" to the remote repository, I would copy all my changes to the 
"remote" workspace, run an update and fix any conflicts that the other site may have 
introduced, make and debug (again to deal with new stuff that the other side introduced), and then 
check into the new repository.
4.  copy all that back into my personal workspace and checkin (since there is new stuff from outside) to the personal cvs.  
5. Put a tag in my personal cvs to indicate this is the result of the merge with the remote cvs.

Really, I don't know any other decent way to do it.

<editorial>
However... this seems like a huge extra amount of effort and time.  I don't 
know why the supervisor is requiring such a thing, but in my opinion this seems 
like the real problem.  Perhaps he's there to make sure that no company 
specific IP goes into the OSS project?  I don't know, but such requirements 
(not the requirement to keep company IP out, the requirement to be checked) 
really kill the use of good revision control and collaboration with the 
external projects, and I'd say that the cost of such oversight really needs to 
be examined.  We contribute to OSS projects here at my company and no one looks 
them over.  We have NDAs and I feel that should be sufficient to keep company 
IP out of the OSS projects.  And besides, my supervisors wouldn't even know how 
to read the code let alone determine if any of our IP is in it (but we've got a 
really small engr dept.).
</editorial>



Jim.Hyslop wrote:
> MKlinke wrote:
>
> > In a simple single-authored project where she is trying to maintain a 
> > much more fine grained control over her revisions that what the 
> > "official" repository allows I'm not sure why she would even want to 
> > "sync" the repositories?  It seems a simple comment in her personal 
> > repository to the effect that "At this point in development the code 
> > was released to the official repository" should suffice.
> >
> > (By "snycing" I'm assuming you mean "make them identical in all 
> > respects including cvs assigned revision levels" at some point in 
> > time )  
> >
> > Given the assumption above, why do you feel "syncing" is important 
> > here?
>
> Well, without any further input from Jill, we're both making assumptions
> here. My assumption was that when she said:
>
>
> > I'll be the only programmer on this
> > project; moreover, my contribution will probably be pretty
> > self-contained (i.e. I don't expect that anyone but me will be
> > modifying the code that I write for this.)"
>
>
> I assumed she meant she would be the only programmer *at her company*
> working on the project, but there could be other people from the open-source
> project, who might make changes.
>
> If Jill is the only person working on the code in any capacity, then a CVS
> repository is overkill. The local, fine-grained control might be more easily
> achieved by making a tarball (or Windows equivalent) when appropriate.
>
> But if she's not, then the whole issue becomes more complex - she will have
> to manage both her changes, and make sure to integrate the changes from the
> main repository. This is what I meant by keeping the two in sync.