New submission from Adrian Irving-Beer <[EMAIL PROTECTED]>:
Hi, found three bugs and thought I'd report them.
Bug #1: "darcs whatsnew --look-for-adds" implies --summary.
Bug #2: Add a file, set as boringfile, "record --look-for-adds",
bogus remove in next whatsnew.
Bug #3: Repo A host X ==get==> repo B host X ==get==> repo C host Y,
repo C cannot see repo A's patches.
Here's #1 and #2, with commands spaced for readability:
% darcs --version
2.0.0pre3 (unknown)
% darcs init
% echo -n 'testing' > _darcs/prefs/author
% echo 'test file 1' > foo
% darcs whatsnew --look-for-adds
a ./foo
% darcs record --look-for-adds --all -m"Patch 1"
Finished recording patch 'Patch 1'
% darcs whatsnew --look-for-adds
No changes!
% echo 'test boringfile' > bar
% darcs setpref boringfile bar
Changing value of boringfile from '' to 'bar'
% darcs whatsnew
changepref boringfile
bar
% darcs whatsnew --look-for-adds
a ./bar
% darcs whatsnew --look-for-adds --no-summary
addfile ./bar
hunk ./bar 1
+test boringfile
changepref boringfile
bar
This demonstrates bug(?) #1:
The --look-for-adds option automatically implies --summary.
% darcs record --look-for-adds --all -m"Patch 2"
Finished recording patch 'Patch 2'
% darcs whatsnew --look-for-adds
R ./bar
a ./bar
This demonstrates bug #2:
Adding a boringfile via --look-for-adds seems to do weird stuff.
% echo 'test file 3' > baz
% darcs record --look-for-adds --all -m"Patch 3"
Finished recording patch 'Patch 3'
% darcs whatsnew --look-for-adds
R ./bar
R ./baz
a ./bar
a ./baz
Bug #2 persists on files added after the boringfile.
This is probably the most disturbing aspect.
% darcs add bar
% darcs whatsnew --look-for-adds
R ./baz
a ./baz
% darcs add baz
% darcs whatsnew --look-for-adds
No changes!
[Bug #2's leftovers have been cleaned up;
now we see if the effect continues.]
% echo 'test file 4' > qux
% darcs record --look-for-adds --all -m"Patch 4"
Finished recording patch 'Patch 4'
% darcs whatsnew --look-for-adds
No changes!
Once you manually clean up the debris from bug #2, it doesn't reoccur.
To reproduce bug #2, it seems to require that you create a file in the
same patch as you assign it as the boringfile, and that you record it
via --look-for-adds. If you do them in separate patches, or if you
"darcs add" the file, the bug goes away.
There's also bug #3, which is related to the lazy patch fetching.
Here's the command flow, with the path and host in the prompt:
[on host 'alpha']
alpha:/tmp/foo% darcs init --darcs-2
alpha:/tmp/foo% echo -n 'testing' > _darcs/prefs/author
alpha:/tmp/foo% echo 'test file 1' > foo
alpha:/tmp/foo% darcs record --look-for-adds --all -m"Patch 1"
Finished recording patch 'Patch 1'
alpha:/tmp/foo% cd ..
alpha:/tmp% darcs get foo bar
Finished getting.
[on host 'beta']
beta:/tmp% darcs get alpha:/tmp/bar bar
Finished getting.
beta:/tmp% cd bar
beta:/tmp/bar% darcs check
darcs: failed to read patch:
Tue Feb 26 16:42:26 EST 2008 testing
* Patch 1
user error (Couldn't fetch d5fa8f5bb76f8f22f0145dc22acae853a59ca6e'
in subdir patches from sources:
thisrepo:/tmp/bar
repo:alpha:/tmp/bar
repo:/tmp/foo
)
The problem here is that although beta:/tmp/bar inherited
alpha:/tmp/bar's sources, it didn't rewrite the host. Hence, lacking
a (local) repo at beta:/tmp/foo, it can't get the patches.
The tricky thing here is that everything seems fine, at least
until you try to do a 'check', 'annotate', 'unpull', etc.
Worse yet, the first command you're likely to run is 'check' (assuming
it isn't 'check' that broke), and to the average user, it then looks
like the repository is corrupt in an irreparable way.
The temporary fix:
[on host 'alpha']
alpha:/tmp/bar% darcs check
The repository is consistent!
[on host 'beta']
beta:/tmp/bar% darcs check
The repository is consistent!
Running 'darcs check' on the intermediary (alpha:/tmp/bar) repo fixes
this, because it loads all the patches where the final (beta:/tmp/bar)
repo can find them.
Otherwise, I've had no troubles with the darcs 2 prereleases so far.
Good to see a great tool get even better. Darcs has the best UI and
best patch mechanic (unordered "bag of patches") of any SCM out there.
I've even got my somewhat SCM-averse co-worker to use it, and without
any trouble whatsoever. :)
----------
messages: 3679
nosy: beschmi, droundy, kowey, tommy, wisq
status: unread
title: boringfile pref bug
__________________________________
Darcs bug tracker <[EMAIL PROTECTED]>
<http://bugs.darcs.net/issue709>
__________________________________
_______________________________________________
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
