[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Problem with duplicate files
From: |
Lorenzo Campedelli |
Subject: |
[Monotone-devel] Problem with duplicate files |
Date: |
Sun, 14 Dec 2003 17:54:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 |
Hello,
while trying to use monotone I stumbled into what I think is a problem.
If two files in the working copy change and they become equal (or two
equal files are changed the same way) then the resulting patch-set is
wrong, as it reports the real change for one file and a deletion for the
next one.
For instance:
1) create 2 files: f1 containing the text "content 1" and f2 containing
"content 2", add them to the work list and commit.
2) edit f1 and f2 so that both contain "content 3"
3) create a patch with monotone diff
You should get something like:
# Old manifest: 6f63d6e873855cf6d9366b49ed446271f4a32958
# New manifest: 2155a0fbe42d1ed3ea309f0d63032206dcc7daec
# Summary of changes:
# delete f2
# patch f1 aff7e13b937501b5415907cc036705598094fb58 ->
41a83abfe126b4f34956af300e1bc745a0cc9317
--- f1
+++ f1
@@ -1 +1 @@
-content 1
+content x
which is wrong, as applying this patch to the original content (e.g. by
monotone update) make you lose f2.
I think this is related to the way patches are produced, considering
manifests as SETS, thus not taking in account repeated files (even in
different directories).
Note that, while the example I gave is very artificial, I hit the
problem by trying to use monotone for real work: importing subsequent
versions of a source tree having copies of some files in different
directories which get updated consistently. This doesn't seem too
uncommon to me.
Do you think this behaviour can be changed?
Anyway I would like to thank you for providing this really good piece of
software.
Regards,
Lorenzo
- [Monotone-devel] Problem with duplicate files,
Lorenzo Campedelli <=