[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Convenient way to commit?

From: Spiro Trikaliotis
Subject: Re: Convenient way to commit?
Date: Wed, 21 Mar 2007 11:22:16 +0100
User-agent: Mutt/1.5.9i

Hello again Hans,

* On Wed, Mar 21, 2007 at 03:07:23AM -0700 Hans Schwaebli wrote:
> so there is no out of the box script or command I just can use when I
> want do do this. Now I know. As I said, Eclipse IDE does allow me to
> do this *high level* commit (including recursive cvs add).

No, there isn't.

> You ask why I want it for daily builds. They are run unattended.
> Sometimes at night. Then I am not there to tell which file to add to
> cvs and which not... see? And I don't know exactly which files are
> created during the build process. Maybe someone adds a new application
> component, that would be an additional jar file generated.

Why would you want to add generated files to CVS? CVS is a tool to
handle sources files. Although you can use it to handle generated files
(JAR, in this case), CVS is clearly not the best tool for this job.

> So I have to zip all this stuff and to commit this one large file.

Why can't you ZIP everything generated and put it on some (intranet) web
space, for example? Why does it have to be in CVS?

> But
> by this the revision history for the artifact elements cannot be
> tracked anymore because they are all in that zip file. So checking in
> everything which is in a certain folder would be better for this from
> my understanding. The only thing which would be needed to do this in a
> productive way is to provide a recursive add command.

As I told, this can be done. It is not very hard to do.

But I really doubt you are using the right tool for your task here.

> This file grows very fast to 2 GB in size. Linux cannot handle this
> large size and the cvs commit command fails unexpectedly.

I am pretty sure Linux can handle such files. Are you sure you are using
a decent version of Linux?

There *might* be a problem with CVS and such big files, I am not sure.
Perhaps, someone else can comment on this one.

> We then
> delete this file on the CVS file system from time to time. Not a nice
> thing.

Now I am stuck. I thought you are checking in the ZIP because you need
the history. If you delete it, you are loosing the history. So, why was
it checked in in the first place, anyway?

> Besides that, CVS needs a lot of time to handle such large
> files when synchronizing, tagging and checking out.

This is right. As I told, CVS is not the right tool for such things.

Best regards,

Spiro R. Trikaliotis                               

reply via email to

[Prev in Thread] Current Thread [Next in Thread]