Re: Convenient way to commit?

I will not die if I can't solve these problems, don't bother...

It has to be in CVS because that would be the easiest way. We have workers which are not working from home or from another office. Deploying a part of this with network or intranet does not work because of security reasons and besides this, it would complicate things, make it harder to automate deployment and would increase the likeliness of errors. Why are the jars in CVS? Because it takes a lot of time to build them, and time is money...

I really don't have time to explore things for days and get such basic stuff like recursive cvs add working. Even this discussion eats too much time. Lets get it pragmatical again please.

Do you ever know how bosses think? Hey boss, please allow Fred to update the Linux machine with a new Linux. It just takes 8 hours. Or maybe two days. Why? Because we have a problem every month because of a two large file. Of course he will consent to it... See? We really have no playtime.

Don't worry, we will replace CVS one day with a better tool, which IS the right thing for the stuff which is needed in development. But it won't happen soon, so I need to ask.

Spiro Trikaliotis <address@hidden> wrote:

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.

--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

From:	Hans Schwaebli
Subject:	Re: Convenient way to commit?
Date:	Wed, 21 Mar 2007 03:35:35 -0700 (PDT)