[pkg-horde] Please adopt/hijack my package

[Roberto C. Sanchez]

Roberto C. Sanchez wrote:
> Lionel Elie Mamane wrote:
> 
>>In my opinion, Subversion's cardinal sin in its branch handling is its
>>poor merge handling, roughly equal to CVS's. By that I mainly mean
>>that it does not keep track of which change (patch) is applied to
>>which branch. This means that if you have a branch A branching from B,
>>about 100 changes have been made in A since branching point, but about
>>50 of those have been merged back into B, to do a complete merge (all
>>changes in A to B) with subversion you must list the 50 other changes
>>(if some of them are in a sequence, they can be grouped together), or
>>risk spurious conflicts. If the VCS you use keeps track of which 50
>>changes are already applied (like tla), then you just say "merge all"
>>(in tla you would use "tla replay A" in a working tree of B) and the
>>VCS applies those 50 changes, no more, no less.
>>
>>In simpler cases (those where "tla star-merge" works, roughly: you do
>>only total merges between directly related branches), the difference
>>is less dramatic, but still real: With subversion, you more or less
>>have to keep track of where the last merge point was with a tag, or in
>>the commit log, or externally and then give that information back to
>>svn on its command line on the next merge. tla (and the other
>>"sensible" VCSs) keep track of this for you, or _compute_ that
>>information when needed.
>>
>>See
>>http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.copychanges.bestprac.track
>>http://subversion.tigris.org/faq.html#merge-using-tags
>>for the official SVN documentation on that simpler case. Notice how
>>many things you have to do manually!
>>
> 
> 
> I see.  Since I do not use branching all that often, much less with
> repeated merges, I did not realize that was a strength on the part of
> Arch.  By the way, that is probably the most concise explanation of a
> killer feature I have seen.  My preference for Subversion has to do with
> my familiarity with it.  If we could get a very detailed HOWTO online,
> starting with the one that is already online on how to work with the
> Horde packages in Arch, I would be willing to give it another shot.  The
> problem I have with the current HOWTO is that it is very sparse, I had
> to use baz instead of tla (based on the recommendation of some people in
> #debian-devel) and I don't understand *why* the steps are taken.
> 

I forgot to add that while the branching/merging may be a very nice
feature, I don't think it is critical for what we do as Horde package
maintainers.  Maybe for upstream development, where you develop two
trees in parallel, but not for simple package maintenance.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-horde-hackers/attachments/20060710/201e2536/signature.pgp