Do you really need a directory in CVS named bsdmake-1.0.orig?
BSD make keeps evolving and I presume you intend to be tracking this.
Putting version numbers into directory names may not be a good idea
since you are not going to be at "1.0" for long.
With CVS you normally use a vendor branch for tracking external
sources and keep your local changes on -HEAD. If you do not do it this
way, much of CVS's automated merging won't work, at least not without a
lot of effort. So this '.orig'/non-'.orig' layout appears to be working
against the way we normally use CVS, unless I've missed something.
cgm> debian ) would have targets to automate everything
cgm> from compiling the package
cgm> 2) I've screwed up the directory positions for peps.
cgm> CVS gurus HEEEEEELPPPPPP!!!!!
With SF.Net CVS you do not have the ability to go and directly repair
damage to the CVS repository. The repository itself is off-bounds to
One course of action would be to file a support request asking
SF.net's CVS meisters to remove the botched import in its entirety
and then start afresh.
From: Cherry George Mathew <berryplumis@ya...> - 2004-07-26 03:34:28
--- Joseph Koshy <jkoshy@...> wrote:
> Do you really need a directory in CVS named
> Putting version numbers into directory names may not
> be a good idea
> since you are not going to be at "1.0" for long.
The version number is for the debian package, not the
upstream version. The upstream version is named (
release tagged ) exactly the same as the freebsd
release engineering tag name.
cvs log Makefile|grep -A2 symbolic
or so should tell you what I'm carping about.
> With CVS you normally use a vendor branch for
> tracking external
> lot of effort. So this '.orig'/non-'.orig' layout
> appears to be working
> against the way we normally use CVS, unless I've
> missed something.
I think you missed the point. The non-'.orig' stuff
contains all the debianized info, including but not
a directory called debian/ with all the package info,
altered Makefiles etc. conforming to the debian file
heirarchy standards ( which are quite different from
the BSDs, no meddling with /usr/local, for example )
etc. So as the 'package maintainer', you're right
about the fact that I would have to painfully sort out
all the stuff in an upgraded version. The nice thing
about this is that I might be able to push this
package into the debian repository, and gleefully
shirk my responsibility in favour of debian
developers' efforts. At that point, we could end of
life the vendor tree here.
> With SF.Net CVS you do not have the ability to go
> project developers.
Uh oh.... I'm sorry about that one.....
The workaround is to do what the NetBSD folks have
been doing ( why am I behaving like one already :-) ).
cvs update -dP while updating the sources.
> One course of action would be to file a support
> request asking
> SF.net's CVS meisters to remove the botched import
> in its entirety
> and then start afresh.
Will do. Thanks for the tip.
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!