Re: file obstruction upon merging an already merged added/moved file (#4649)
Julian Foad wrote: On 06/09/16, Stefan Hett wrote: What still is unclear to me is that SVN handles the case when I do an auto merge but not when using the cherry pick merge. [...] An auto merge doesn't try to merge back a revision that it can determine has already been applied to the target branch. Maybe it's best to have a quick look at this at Berlin, if time permits? Sorry, I can't come to Berlin this year [...] but I'm sure someone else will be glad to go through it with you. - Julian
Re: fsfs: Segfault when rep line lists the all-zeroes checksum
On 08.09.2016 18:51, Daniel Shahaf wrote: Stefan Fuhrmann wrote on Thu, Sep 08, 2016 at 17:51:47 +0200: It appears that it might be very hard to get such data into the repository because we use the same parser function in e.g. the network layer and the editor drivers. Not sure we all for MD5s etc. to be missing in all relevant places. Let's get this function to return a non-NULL svn_checksum_t object for the all-zeroes checksum when we next revv it. (This would be a better interface since it would have fewer special cases.) That would make sense. Although I would hesitate to revv the API if that was the only change: We call it in ~30 places and probably use the current quirk to provide backward compatibility with old clients and such. Migrating these invocations seems risky. -- Stefan^2.
Re: fsfs: Segfault when rep line lists the all-zeroes checksum
Stefan Fuhrmann wrote on Sat, Sep 10, 2016 at 20:50:28 +0200: > On 08.09.2016 18:51, Daniel Shahaf wrote: > >Stefan Fuhrmann wrote on Thu, Sep 08, 2016 at 17:51:47 +0200: > >>It appears that it might be very hard to get such data into the > >>repository because we use the same parser function in e.g. the > >>network layer and the editor drivers. Not sure we all for MD5s etc. > >>to be missing in all relevant places. > >Let's get this function to return a non-NULL svn_checksum_t object for > >the all-zeroes checksum when we next revv it. (This would be a better > >interface since it would have fewer special cases.) > That would make sense. Although I would hesitate > to revv the API if that was the only change: We call > it in ~30 places and probably use the current quirk > to provide backward compatibility with old clients > and such. Migrating these invocations seems risky. Of course: if another public API inherits the "all-zeroes checksum is represented as a NULL struct" promise of svn_checksum_parse_hex(), then we can't upgrade the svn_checksum_parse_hex() call in that (other) API's implementation without revving that API too — for the same reason that we don't make the change to svn_checksum_parse_hex() without revving it. Cheers, Daniel
