http://bugzilla.novell.com/show_bug.cgi?id=598615
http://bugzilla.novell.com/show_bug.cgi?id=598615#c2
Michael Meeks
why do you remove the conflicting file ? You could just move on off the other files, which are checked out beside.
Because I don't trust them; and I want to discard the change, with a very high degree of certainty that what I have is what is in the repo. I guess I'm looking for an equivalent of: $ git reset --hard :-)
"osc update" is not restoring the file, because it is declared as conflicted. So you need to declare the conflict as resolved first. After that "osc up" will also restore the file again. This is IMHO exactly the same as svn and git is doing it.
That was (obviously) really non-obvious to me :-) And I didn't really want to resolve anything; just throw it all away.
The file must be stored in the system with history to guarantee that we get the original source for a package, independend if some upstream server got screwed up or not.
of course ! :-) don't mistake me saying "we should separate big binary files" for "we should re-download pristine source each time" or "we should not do revision control". Quite the opposite - I just believe that we should store the big binary files in another RCS - preferably allocating each a unique name at checkin time: ooo-build-1.2.3.tar.bz2-1 or whatever ;-) and that this can be fetched from the repository just once; and of course will never change [ in the binary repository ]. That leaves some rather small, human-readable, easy-to-git spec files, changes, patches etc. left.
But we will allow server and client side downloads from original side via source services soon.
It would be good if before re-downloading stuff, we checked whether the file already existed in the .osc directory (with the same md5sum). That would be -waay- quicker for people far away from Nurnberg (or Portland ;-). Thanks. -- 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.