[darcs-users] multi-user behavior

Zack Brown zbrown at tumblerings.org
Sat Jul 26 14:14:40 UTC 2003


On Sat, Jul 26, 2003 at 09:29:55AM -0400, David Roundy wrote:
> On Fri, Jul 25, 2003 at 07:05:36PM -0700, Zack Brown wrote:
> > In tst/ I added some new files and removed some others, and did a 'darcs
> > record'. This worked fine. But from tst2/tst when I did a 'darcs pull
> > ../tst', it removed the proper files from the archive, but didn't delete
> > them from the directory.
> > 
> > My question is, why not?
> 
> I'm not sure.  In the test I just ran (admittedly simpler than you
> describe, just one file involved) it does get deleted.  Can you send me a
> series of commands that leads to this behavior? Sounds like a bug to me,
> albeit a pretty harmless one, which is probably why I haven't noticed it.

Going back over the sequence of events, I see that I actually made a
modification to the file in tst2/tst before doing a pull, and that's
what resulted in the file not being deleted. When I redid the test with
an unedited file, it was deleted as expected.

Nevertheless, darcs still silently did not remove a file, and gave no
indication that the file's status had changed. That seems to be a
problem in itself. See below.

> 
> > assuming tst2/ is owned by someone else, how are they to know that a file
> > is or is not in the repository? To be absolutely sure, they would have to
> > do something like check _darcs/current each time they wanted to edit a
> > file.
> 
> Well, if they run darcs whatsnew regularly (I tend to do so almost
> instinctively) they'll pretty soon notice that they're editing a file that
> isn't in the repo.

Not necessarily. 'darcs whatsnew' only fails to report on the changes in
that file. It doesn't actively say, "this file hasn't changed." So if that
file is the only one changed, then yes, the developer would be likely to
notice that something was up. Still, it would be a bit surprising to see
one's changes go unnoticed by darcs, without any explanation.

But maybe the developer is editing many files, all part of one basic
enhancement. In that case, they could easily miss the 'darcs whatsnew'
evidence. But when they did a push (or the project leader did a pull),
everything would work out fine, except the one file would not go
through. Maybe no one would notice right away, but people would start
testing the new code and find compilation bugs. Their time will have
been wasted.

And once the discovery is made that the file had been deleted but not
re-added, it's not just a simple matter of re-adding the file.
Presumably it was deleted for a reason. So that will mean more coding on
the part of the developer, probably in a completely different file. If
he or she had done a lot of work that depended on the changes being in
that one file, then all of that work will have to be redone as well.

This whole problem seems to be one of conflict resolution. If the developer
had been notified at the time of their initial pull, they might have saved
a lot of time and energy, for themselves and others. Here's a different
situation I ran into:

In the tst/ directory, I edited a file. In tst2/tst, I edited the same
file, on the same line of the file. So the two files in tst/ and
tst2/tst have both been altered on the same line, and are both different
from what is currently in the repository.

Now, the tst/ developer does a 'record', and after that, the tst2/tst
developer does a pull. At this point, the change made in tst2/tst is
completely wiped out, and replaced with the change made in tst/.

This seems like another case of a conflict, in which darcs should not
simply silently perform the 'proper' task, but should stop, alert the
user, and invoke a conflict-resolution tool if one is available.

Be well,
Zack

> -- 
> David Roundy
> http://www.abridgegame.org
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at abridgegame.org
> http://www.abridgegame.org/mailman/listinfo/darcs-users

-- 
Zack Brown




More information about the darcs-users mailing list