monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: Monotone and changesets


From: Bruce Stephens
Subject: [Monotone-devel] Re: Monotone and changesets
Date: Wed, 24 Nov 2004 12:24:46 +0000
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux)

Colin Walters <address@hidden> writes:

[...]

> Hm.  My problem with not having GUIDs (logical file identity) isn't
> so much that a patch could fail to apply, as that it could appear to
> apply successfully, but to the wrong file.

There are presumably two cases (well, probably more than two, but two
will do for the moment): a user sends a patch, but in the meantime
some files have moved in the repository; a user sends a patch and (as
part of the patch) wants to move some files around.

It's clearly convenient (at least in some ways) if the files
themselves contain a stable indicator---it's much less easy to lose
than anything else I can think of.  It doesn't seem essential, though:
in either of those cases, if the user can precisely indicate what
source tree their patch is relative to, then anyone with access to a
suitable repository can work out which files are which.  So someone
using darcs presumably needs to ship tarballs with the output of
"darcs --context" or something, and with monotone, the SHA1 of the
changeset.

The second case makes more of a case for arch tags: if a random user
wants to muck around with the source and doesn't want to use a version
control system, then it seems most likely that they can get accurate
rename information if the files themselves contain tags.

Probably such a user isn't going to have a tool that can produce
rename information from arch tags.  Or (just as likely) will have it
installed but won't know about it.

Anyway, in practical terms it looks like GNU Arch is the only system
that's going to use arch tags, so I imagine they'll have impact
limited to projects that have significant developers who use Arch.

The use case strikes me as important, though.  It emphasises that
people releasing source code ought to think about how they'd like bug
reports and patches sent, and that developers of revision control
systems ought to think about ways of supporting that.  I don't think
that support is there yet, but I'm also not at all convinced that we
need to use arch tags.




reply via email to

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