mainSavannah Administration - Support: sr #106105, Problems with cvs commit

 
 

sr #106105: Problems with cvs commit

Submitter:  Laurence Finston <lfinsto1>
Submitted:  Thu 29 Nov 2007 09:20:39 PM UTC
   
 
Category:  Source code repositories - developer access Priority:  5 - Normal
Severity:  4 - Important Status:  Done
Privacy:  Public Assigned to:  Beuc
Operating System:  GNU/Linux Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 10 Dec 2007 11:31:13 PM UTC, comment #10: 

Ok, all done :)

Sylvain Beucler <Beuc>
Mon 10 Dec 2007 10:27:17 PM UTC, comment #9: 

Please remove the following directories as well:

[metaexchange] / metaexchange / scantest / SNAPSHOTS
[metaexchange] / metaexchange / atest / SNAPSHOTS
[metaexchange] / metaexchange / dc_test / SNAPSHOTS
[metaexchange] / metaexchange / lo_db / SNAPSHOTS
[metaexchange] / metaexchange / pica_db / SNAPSHOTS
[metaexchange] / metaexchange / texinfo / SNAPSHOTS
[metaexchange] / metaexchange / ztest / SNAPSHOTS

> Please let me know if things are ok for you.


Yes.  The snapshot directories aren't important.  As long the problem with committing files is fixed, you might as well close this item.  I'll let you know if I have any more problems.

I'll look into using the Savannah download area, but this isn't urgent.

Thanks again for all your help.

Laurence

Laurence Finston <lfinsto1>
Mon 10 Dec 2007 07:12:56 PM UTC, comment #8: 

Hi,

I removed the 'SNAPSHOTS' directory.

Indeed CVS does not allow data to be truly removed, so this had to be done by an admin.

Please let me know if things are ok for you.

Sylvain Beucler <Beuc>
Mon 10 Dec 2007 09:41:53 AM UTC, comment #7: 


> To sum up I think it's best to move the snapshots outside of the
> repository, and select a subset of snapshots you want to publish
> (the recent ones, one by month?) - either do it yourself or I can
> script some export locally at Savannah.


I've given this some thought, and the snapshots don't really need to be in the CVS repository.  Nor is it important that I update my webpages before any changes are made.  If it's a dead link, it will just be a dead link.  I've got links to the server where they will remain;  the most recent one, that is.

Keeping every snapshot is unnecessary.  I could use the "named configuration" feature, or whatever it's called.

To the best of my knowledge, I can't remove anything from the repository completely;  I can only cause it to be put in the attic.  So, would you please delete the snapshots?  You can remove the entire `SNAPSHOT' directory.  I don't know whether it would be helpful for me to delete them first, so please let me know if this is necessary.

Thanks,

Laurence





Laurence Finston <lfinsto1>
Sun 09 Dec 2007 12:59:24 PM UTC, comment #6: 

Hi,

- Yes, there is a download area that is hosted at Savannah, and it's different than the alpha.gnu.org/ftp.gnu.org. However, GNU projects tend not to use it, because they don't really need it. I suggested using it because the direct SFTP access makes it suitable for hosting temporary files, which would be cumbersome at ftp.gnu.org because of the directives-based upload system.

- It should be possible to extract the snapshots individually - extracting all the ~800 snapshots sounds a bit too much though. Maybe select a subset of the snapshots you'd like to export. Note that you can do this if you want, by grabbing the raw CVS file from rsync://cvs.sv.gnu.org/sources/3dldf/3dldf/Group/SNAPSHOTS/ and extracting the revisions as you want using 'co'.

- The CVS web interface is indeed misleading about binary files. I think most free software revision control systems offer limited support for binary files. In our case this is extremely inefficient because the 1.5GB file needs to be entirely rewritten at each commit, which can explain why it is long ;)


To sum up I think it's best to move the snapshots outside of the repository, and select a subset of snapshots you want to publish (the recent ones, one by month?) - either do it yourself or I can script some export locally at Savannah.

Sylvain Beucler <Beuc>
Sun 09 Dec 2007 11:32:45 AM UTC, comment #5: 


> Hmm, for tarballs, don't you want to use the download area?
> (possibly the Savannah one, which can be managed by SFTP, unlike
> ftp.gnu.org).


Maybe the Savannah one, of which I was not aware.  I know there's a download area for each of my projects, but I didn't know this was different from the CVS repository or ftp.gnu.org.   Frankly, I've never worried about it too much.

I certainly don't want to use ftp.gnu.org for the snapshots, because these are what I've been calling my "development versions".  Everytime I work on the package, I make a snapshot.  An official release or even an alpha isn't possible at present.

This isn't really urgent, since I also use the ftp server at the computer center in the town where I live.

> In particular, 3DLDFsnp.tar.gz,v alone has a size of 1.5GB...


Okay.  Would you like to remove it from CVS?  Please wait until I have a chance to update my webpages, README, etc., before you do, though.  If so, I'll try to do this within the next couple of days.  (But see below.)

"It certainly doesn't pay to calculate a diff. Have you considered implementing a way of turning this off, perhaps sometime in the future? I seem to remember this being discussed elsewhere before."

> You mean disabling diffs? CVS doesn't do diffs on binary files. 


According to the CVS web interface, there are diffs.  I don't think I've ever tried this before, but just now it told me:
"- Binary file revisions differ -"  Whatever, it doesn't matter.

Ideally, I would like people to have access to the old snapshots, but it's not a big deal.

Please tell me what you'd like me to do.

Laurence


Laurence Finston <lfinsto1>
Sat 08 Dec 2007 09:52:04 AM UTC, comment #4: 

Hmm, for tarballs, don't you want to use the download area? (possibly the Savannah one, which can be managed by SFTP, unlike ftp.gnu.org).

In particular, 3DLDFsnp.tar.gz,v alone has a size of 1.5GB...


"It certainly doesn't pay to calculate a diff. Have you considered implementing a way of turning this off, perhaps sometime in the future? I seem to remember this being discussed elsewhere before."

You mean disabling diffs? CVS doesn't do diffs on binary files.

Sylvain Beucler <Beuc>
Sat 08 Dec 2007 09:38:20 AM UTC, comment #3: 

Thank you, Sylvain.  It's working now.  I take it this problem has nothing to do with my project, i.e., it's not my RCS files that ViewVC doesn't like?

By the way, unless I'm adding a file, I usually submit batches of files, including a tarball containing the current result of `make dist'.  It always takes a long time for this to be committed, obviously because of the time it takes to calculate a diff.

It certainly doesn't pay to calculate a diff.  Have you considered implementing a way of turning this off, perhaps sometime in the future?  I seem to remember this being discussed elsewhere before.

It's not a big problem;  just a bit tiresome waiting for the snapshot to be committed.

Thanks again,

Laurence

Laurence Finston <lfinsto1>
Fri 07 Dec 2007 11:39:06 AM UTC, comment #2: 

You sent by mail:

> Yes, right now:  Thu Dec  6 23:50:11 CET 2007
>
> Not just a slow-down;  the commit timed-out and I couldn't load

any webpages from Savannah.

That's ViewVC for you: eating all the CPU when processing some RCS files it doesn't like...

I killed the processes, I guess we need to find alternatives to ViewVC.

Sylvain Beucler <Beuc>
Thu 29 Nov 2007 10:13:01 PM UTC, comment #1: 

I don't know what I can say, the system appears to be fine.

Can you note the precise time (GMT) when there is a slow-down?

You may also want to check the system's health through
http://savannah.gnu.org:8080/cacti/graph_view.php
and see it anything special happens at that time.

Sylvain Beucler <Beuc>
Thu 29 Nov 2007 09:20:39 PM UTC, original submission:  

I've been trying to check files into the source repository for GNU 3DLDF.

Yesterday and today (2007.11.29) I've been having trouble with `cvs commit'.  It works, but very, very slowly.  This afternoon, it worked fine, but this evening it seems to have ground to a halt. 

It seems to work better when the files are named in the command.  It works much worse when none are named.

Thanks,

Laurence Finston


Laurence Finston <lfinsto1>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Beuc (Posted a comment)
  • -email is unavailable- added by lfinsto1 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-12-10 Beuc StatusNone Done
        Open/ClosedOpen Closed
    2007-11-29 Beuc Assigned toNone Beuc

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code