Just to be clear, the "No CVS" rule relates to avoiding the bleeding edge, not anything to with CVS per se, yes? Or is it that the CVS stuff is not packaged as thoughtfully to build right out of the box?
I ask because it has occurred to me that CVS neatly solves the problem of my jumping around between win32 and Linux: if I pull source down onto my Linux box and hack it to make it work over there, then I just commit and do an update on my win32 box and make sure everything still works there. If not, another iteration and all should be OK, off to OS X to conquer another platform.
Sound right?
kt
Kenny Tilton writes:
Just to be clear, the "No CVS" rule relates to avoiding the bleeding edge, not anything to with CVS per se, yes? Or is it that the CVS stuff is not packaged as thoughtfully to build right out of the box?
Right -- depending on the project, the source in CVS can be almost guaranteed to be broken. That's just an issue with using the development branch.
I ask because it has occurred to me that CVS neatly solves the problem of my jumping around between win32 and Linux: if I pull source down onto my Linux box and hack it to make it work over there, then I just commit and do an update on my win32 box and make sure everything still works there. If not, another iteration and all should be OK, off to OS X to conquer another platform.
Sound right?
That's how it's supposed to work. You could have more useful comments to your commits (say, "changed use of cc-defstruct to defstruct"), but it's not strictly necessary :). That kind of thing can be useful when trying to figure out when something broke, though.
Thomas F. Burdick wrote:
Kenny Tilton writes:
Just to be clear, the "No CVS" rule relates to avoiding the bleeding edge, not anything to with CVS per se, yes? Or is it that the CVS stuff is not packaged as thoughtfully to build right out of the box?
Right -- depending on the project, the source in CVS can be almost guaranteed to be broken. That's just an issue with using the development branch.
Lawdy, where I come from that is grounds for a firing squad. By which I mean, the group's source code repository is what everyone works against, so lord help you if you commit broken code.
OTOH, the config/make stuff I guess is precisely the kind of thing I can see falling through the cracks since developers will have stable build environments in place and would not be using the CVS config/make stuff.
I guess my question is, did anyone see me making a mistake in how I was trying to build? For example, should there have been a file called "configure" (no extension)? Or was I supposed to make one with autoconf? Or...
I ask because it has occurred to me that CVS neatly solves the problem of my jumping around between win32 and Linux: if I pull source down onto my Linux box and hack it to make it work over there, then I just commit and do an update on my win32 box and make sure everything still works there. If not, another iteration and all should be OK, off to OS X to conquer another platform.
Sound right?
That's how it's supposed to work. You could have more useful comments to your commits ....
I'll do my best once I get a solid base of cvs code. Unfortunately nothing is safe when I take up a keyboard (ie, I refactor /a lot/), so by the time I get everything working again, nothing else does.
kt
Kenny Tilton writes:
Thomas F. Burdick wrote:
Kenny Tilton writes:
Just to be clear, the "No CVS" rule relates to avoiding the bleeding edge, not anything to with CVS per se, yes? Or is it that the CVS stuff is not packaged as thoughtfully to build right out of the box?
Right -- depending on the project, the source in CVS can be almost guaranteed to be broken. That's just an issue with using the development branch.
Lawdy, where I come from that is grounds for a firing squad. By which I mean, the group's source code repository is what everyone works against, so lord help you if you commit broken code.
Some projects are horrible that way, and "broken" actually means "doesn't work" -- with open source, there aren't any firing squads (just project forks). I try to avoid such messes :). With better run projects, the bleeding edge works on at least the developers' systems.
OTOH, the config/make stuff I guess is precisely the kind of thing I can see falling through the cracks since developers will have stable build environments in place and would not be using the CVS config/make stuff.
I guess my question is, did anyone see me making a mistake in how I was trying to build? For example, should there have been a file called "configure" (no extension)? Or was I supposed to make one with autoconf? Or...
configure scripts usually aren't in the source tree, because they're generated by something else. So, look for a configure.ac, in which case you use autoconf, or look for a script, like makeconfig or (in this case) autogen.sh.
That's how it's supposed to work. You could have more useful comments to your commits ....
I'll do my best once I get a solid base of cvs code. Unfortunately nothing is safe when I take up a keyboard (ie, I refactor /a lot/), so by the time I get everything working again, nothing else does.
At a previous job, insufficient CVS comments would get you in trouble. If people were going to go out after work, you'd usually hear, "is everyone ready?" "I just have to go through todays diffs, so I can check them in." "We'll meet you at the bar."
-
Kenny Tilton -
Thomas F. Burdick