On Tue, Oct 28, 2003 at 02:37:21PM -0500, Ross Patterson wrote:
> But the good news is that it doesn't look like what you're trying to do is
> all that hard with normal CVS. Instead of trying to "cvs import" each
> release, try just checking the updated code in to CVS. Tag it where tags
> make
On Mon, Oct 27, 2003 at 11:52:19AM -0800, Mark D. Baushke wrote:
> CVS is a more mature product and needs to move a bit more conservatively
> oriented when considering large changes in how it works. I suspect there
> will be a place for cvs even after svn 1.0 is released.
I know, it's easy to turn
On Mon, Oct 27, 2003 at 01:22:23PM -0500, Greg A. Woods wrote:
> BTW, those are design limits, not bugs. They are caused by the way CVS
> tracks _the_ one vendor branch. The multiple vendor-branch hacks
I see, I've never considered them bugs. Just recently I 'discovered'
subversion (svn), a cvs
On Sun, Oct 26, 2003 at 02:07:36PM -0800, Mark D. Baushke wrote:
> If you have concrete suggestions or a good vision you wish to share on
> the future of cvs, please share them here.
Mainly those import issues are what bothers me most. I'll try to come up
with a concrete way of dealing with vendo
On Sun, Oct 26, 2003 at 12:59:48PM -0800, Mark D. Baushke wrote:
> I have not tried to do it, but you might be able to use multiple vendor
> branches by using the -b switch to import and then have the vendor be
> LINUX_0_01, LINUX_0_10
I've already thought about this solution. It works, but IMHO
One of my uses of CVS is to record various releases of software, to see
changes between them. For instance, is kind of interesting and educative to
have all releases of linux kernel since linux-0.01 in a CVS repository so
you can see how the kernel evolved through time. I try to keep the original
