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

Re: XS-X-Vcs-XXX field not (yet) announced

On Sat, 23 Sep 2006 09:58:39 +0200, martin f krafft <madduck@debian.org> said: 

> also sprach Manoj Srivastava <srivasta@debian.org> [2006.09.23.0936
> +0200]:
>> Seems to me that this is fit for centralized single branch
>> repositories only -- at least, I fail to see how I can represent my
>> mlti-branch (no yet multi-repository) configs that need at least 3
>> different branches from three different categories to pull together
>> my Debian packages.

> I would call this a deficiency with tla/baz.

        Sure, you can call things whatever you want to. There is
 nothing that really constrains you to reality.

        The role of arch is to make life easier for me, the developer,
 not to fit some arbitrary criteria like  all projects must be
 describable by a single URL.  If you think lacking that characteristic
 is a failure of the version control system  ... Umm, I am speechless.

        See, upstream comes from its own source, it seems a good idea
 to keep sources for different packages separate. I can do
 tla_load_dirs to maintain the upstream branch, detect and handle file
 renames, etc.

        All my ./debian dirs have more in common with each other than
 the upstream package -- so the ./debian dir in make is very
 similar to the ./debian dir in ucf --  than it is to either make or
 ucf itself.  Makes sense to derive all ./debian dirs from an
 archetypical parent -- this allows me to make changes (like when I
 created md5sums for files in packages) -- by replaying changes to the
 parent in all the children, and updating the checked our dirs (one
 change, one simple one-off script).

        I also have one common */debian/common dir (which is where the
 bulk of the md5sum changes occured).

        So my lay out gives me flexibility, reduces the time when
 creating new packages, and reduces work required to make common
 changes across my packages, and also the work required when there is a
 new upstream.

        It would be far harder to automate the upgrade-to-new-upstream
 scripts were it  all munged into one unholy mess of a  combined

> The point about the field is to allow people easy access to the
> source. That, by default, kind of rules out GNU arch already, and
> especially so if you need to take 100 steps just to get there.

        A hundred steps? I see you either have no idea what you are
 talking about, or are trolling, so I shall drop this conversation

        I fear I have been trolled. I have lost. Sorry for the noise.

When you're dining out and you suspect something's wrong, you're
probably right.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: