[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Moving a sourceforge project to arch
From: |
Brian May |
Subject: |
Re: [Gnu-arch-users] Moving a sourceforge project to arch |
Date: |
Fri, 27 Feb 2004 09:58:26 +1100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
>>>>> "Michael" == Michael McCracken <address@hidden> writes:
Michael> I get offers of help from people unfamiliar with version
Michael> control, and who don't have time to learn CVS. I can tell
Michael> them how to get the code, but they don't want to commit -
Michael> they want to send me their changed version. I have to put
Michael> up, since beggars can't be choosers. Does anyone have an
Michael> opinion on whether or not arch makes this kind of thing
Michael> easier to handle? If so, why, and how would you handle
Michael> it?
I get the impression from the above that you mean that they will send
you the entire tree, not just the patches?
Why do they not want to do commits? Is this because it is too hard, or
is it because they are scarred of making mistakes and/or making
changes you dislike?
If contributors don't want to use cvs diff to create patch files, I
don't think arch can help. It means you would have to isolate what
changes they made, and propagate them across to your tree.
If contributors do use cvs diff though to generate patches, there seem
to be two ways they can do the same thing with tla:
1. tla changes --diffs | mail -s subject ...
(could be done via script)
2. tla changes -o tmpdir && tar -czvf tmpdir.tar.gz tmpdir
send tmpdir.tar.gz via MIME mail.
(could be done via script)
3. distribute scripts that will automatically create a local archive
and branch your tree to the local archive, and mirror it to a
publicly accessible location.
4. tla commit to central location. Obviously this may not be a valid
option here.
(not tested)
I believe 1. is easiest to do, but I think you will have problems with
renamed/moved files, 2 will work with renamed and moved files, but the
result is binary. 3 seems to be the preferred approach, however, it
requires each contributor have a publicly accessible mirror.
--
Brian May <address@hidden>