Wouter,

--On 9 June 2011 16:39:10 +0200 Wouter Verhelst <[email protected]> wrote:

> On Tue, May 31, 2011 at 10:54:09AM +0100, Alex Bligh wrote:
>> This commit:
>> * Adds a "temporary" option, which causes a unique file to be
>>   created, which is unliked as soon as it is created (and thus
>>   will not be present on exit). This is used for creation of
>>   temporary disks.
>> * Will create a file, if "filesize" is specified and the file
>>   is not present or is zero length (useful in conjunction with the
>>   above).
>
> I'd created the 'prerun' and 'postrun' stuff so that this kind of
> behaviour could be implemented without having to special-case it. While
> I have nothing against this particular patch per se, I'd be interested
> in learning why you feel they're not sufficient before I'll accept it.

I think the answer here is because there is no way from prerun
or postrun to feed back the name of the temporary file created. Just
to be clear, what it's doing is creating a temporary file based on
the pathname specified in the export session, and using that. So multiple
clients can say "I want a 50Gig disk that will go away after I use
it". Pre-run could create one, with a fixed filename, but I see
no way to avoid overwriting the files of existing clients.

>> Available from git.alex.org.uk as usual.
>>
>> Wouter: please note my repo contains a revert of your recent patch
>> to allow specification of the port in the config file, because it
>> causes nbd-server to SEGV on "make check". You may or may not
>> want to pull that.
>
> In the future, it's preferable if you do not merge a broken commit,
> rather than adding another commit that reverts it. Because now I have to
> either cherry-pick your commits, or revert your revert commit, both of
> which are rather confusing :-)
>
> ("git checkout 53122e4d232; git branch -D master; git branch master"
> would've done that, if you'd already merged before)
>
> I'll just do the cherry-pick thing this time, four commits isn't a huge
> issue, but please remember that for the future.

This is my git-newbiness. The problem I had was that I did a
git pull, assumed it would all work (fatal mistake!), did some
patches of my own, committed them to my tree, then noticed the
patch in master broke it. I couldn't see an obvious way to
revert a patch in such a way that it didn't appear in the
history, but still keep my own git history (I think I might
have already pushed my changes and mailed them to the list).
What I really wanted was to reset to prior the broken patch
and autoreapply my stuff, then somehow clean up git.alex.org.uk.
Suggestions and free git training welcome!

Once we've sorted out what you are and aren't pulling from the latest
set, I'll try and resync my repo so it's the same, e.g. by reverting
my revert.

-- 
Alex Bligh

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general

Reply via email to