Now repoman complains about editor backup files. This did not occur before. Its pointless to consider such files, as they're ignored by CVS anyway and therefore they need to be ignored by repoman too. file.name 1 /usr/portage/net-libs/jaimlib/jaimlib-0.5.ebuild.~1.2.~: char '~'
It's a regression then, bug 46070 Thought this was a dupe at first, apparently I was mistaken ;)
Created attachment 70100 [details, diff] Diff of 2.0.51.22 repoman to 2.0.53_rc4 repoman (In reply to comment #0) > Now repoman complains about editor backup files. This did not occur before. It's not a regression. It's been this way for a long long time. (patch proves arch vs ~arch hasn't changed) > Its pointless to consider such files, as they're ignored by CVS anyway and > therefore they need to be ignored by repoman too. > > file.name 1 > /usr/portage/net-libs/jaimlib/jaimlib-0.5.ebuild.~1.2.~: char '~' How is it pointless? Should digest generation ignore them as well? How about manifest verification?
This is valid behaviour from where I sit. Previously, repoman was silently filtering out certain files for commits. This is an easy way for manifest creation to bite you in the ass- with glep31, we have strict requirements for what's allowed for naming of files in the tree. Repoman's enforcing it. Key thing to note is that not everyone is going to be using repoman for commiting to CVS (SVN fex is an alternative), so the list of what to ignore gets larger and larger. Either way, I'm for repoman being stringent, less transparent about the files it silently ignores, and glep31 flat out marks those files as invalid. :)
Re: Comment #2 Should digest generation ignore them as well? Yes. How about manifest verification? Yes. As I said, this was the previous behavior and I have a few hundred files ending in ~ in /usr/portage to prove it. Re: Comment #3 How about a compromise in repoman. There's so many tools out there which produce backup files, it will be a fight to use repoman with them. Can we change repoman so that it has this behaviour: The only time such an editor backup file should be included is when it has been scheduled to be added to CVS. (eg. cvs up shows "A"). Therefore, there are two cases: 1. If the file ends in "~" and it HAS NOT been scheduled to be added to CVS etc., then ignore it, but print a warning message. 2. If the file ends in "~" and it HAS been scheduled to be added to CVS etc., then treat like any other ebuild-related file. The intention here is if someone went to the trouble of scheduling it to be added, then it surely is an important file related to the ebuild.
Or... find -name '*~' -exec rm {} \; I know what cvstree code was doing prior... it's invalid behaviour imo. You're commiting that package and all subdirs, trying to do filtering in it of anything but CVS and .svn dirs I view as screwed up. Tag in support to filter out one filters backups, we start getting into the mess of filtering out each variation an editor does for it's backups. Additionally... you're commiting to a vcs. Seems kind of redundant relying on local editor backups for it.
Closing this one. See comments inlined as to why this really is a bad thing for repoman to silently do; it's not too hard for people to stick a bash func in their bashrc that cleanses out backup files that $EDITOR likes to leave behind, rather then building up lists of filters. Existing code in repoman will survive since their's no reason to kill it, but don't like expanding it any further, especially since we now have requirements on chars for filenames in the tree.
