[Bug 598615] New: osc re-downloading fetish ...

http://bugzilla.novell.com/show_bug.cgi?id=598615 http://bugzilla.novell.com/show_bug.cgi?id=598615#c0 Summary: osc re-downloading fetish ... Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: BuildService AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mmeeks@novell.com QAContact: adrian@novell.com Found By: --- Blocker: --- I have a package that includes a large source archive (who does not ?). I try to do my checkins via ssh to Nurnberg where I can get a faster connection; so then I check it out locally It takes of the order of five minutes to download. Then I notice there are conflicts; not trusting osc at all to get that right; I delete the file (just the .spec file) with the conflicts. That's easy I think - I'll just re-check that one file out: Oh dear - that doesn't work. osc update # doesn't restore the file osc update --help # shows no options that might be helpful here osc checkout # moans that there is nothing to checkout. Nevermind I think - osc has all the files, and their md5sums in the pkg/.osc directory - this should be easy. cd .. osc checkout pkg . Why, oh why - do we have to store the file twice locally, with it's md5sum, and then re-download it when we check the same thing out ? As a follow-up question: why do we store big binary files in a revision control system anyway ? this is IMNSHO a horrible mis-fit: we should store the big, immutable, binary files in a respository, and keep the small, human read-able patches, spec files etc. in the RCS [ preferably git ]. (cough build-buddy) etc. ;-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.