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

[Kevin Smith]

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:
,,get.dists--arx--1.0--patch-186.20041001T034847

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:
,,get.dists--arx--1.0--20041001T034847

or maybe

,,arx--get.dists--20041001T034847

> 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.

Thanks,

Kevin