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.
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
