[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Arx-users] Error trying to pull ArX 2.0

From: Kevin Smith
Subject: Re: [Arx-users] Error trying to pull ArX 2.0
Date: Sat, 02 Oct 2004 20:41:19 -0400
User-agent: Mozilla Thunderbird 0.8 (X11/20040916)

Walter Landry wrote:
Kevin Smith <address@hidden> wrote:
Hmm. I still don't appreciate the current directory getting cluttered with ,, files. Would it be possible to create the destination directory first (perhaps with a mangled name, like "project-incomplete"), and create all the temp files inside it?

The temp directory has a mangled name indicating the command, the
revision, and when it was executed.  How would you do it differently?

Only slightly, I guess. Remember that this was my very first experience with ArX, so I really didn't know what to expect. I wasn't even certain that the 'get' would create a subdirectory, rather than dropping the gotten archive into the current directory.

So when I saw this:

it wasn't clear to me that this was the one and only file (directory) that would get orphaned. In my mind, this was just one of the many patches that it was going to try to pull, so I was imagining a whole pile of these ending up in my current directory.

Now that I understand the situation better, and your explanation of the temp filename, it makes much more sense. Maybe it really is ok (best) as it is. I guess my primary expectation would be that it would immediately create the project directory (named 'arx' in this case) first, and do all its work in there.

My secondary thought would be that it might create a directory named something like: arx-incomplete or maybe ,,arx and then rename it at the end of the operation.

But I do like having more information about what was being attempted at the time. I guess the word that really threw me off was patch. I would much rather see something like:

or maybe


Also, if the command aborts itself for some reason, all of the temp
directories should delete themselves.  If you abort it (e.g. with
Ctrl-C), then it doesn't clean up after itself.  That would involve
installing a signal handler, which is more complicated than the
cleanup via destructors that we have now.  It wouldn't be impossible.
Basically, I would have to register each of the temp directories in a
global list that the signal handler could see.

If I go down that road, I would also like to do a similar thing for
archive locks.

I'm not particularly worried about that level of cleanup.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]