[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: tagging-method explicit implementation
From: |
Mark A. Flacy |
Subject: |
[Gnu-arch-users] Re: tagging-method explicit implementation |
Date: |
Thu, 28 Aug 2003 20:14:49 -0500 |
>>>>> "Maksim" == Maksim Lin <address@hidden> writes:
Maksim>
Maksim> Yes, yes & yes.
Maksim> I have been thinking the last couple of days about exactly the same
thing.
Maksim> I completely agree that move operations are pretty infrequent, at least
in Java
Maksim> programming (which is what I'm familiar with these days). In fact most
movement
Maksim> is done when you refactor your code, which would normally involve
moving files
Maksim> around to different directories rather then moving whole dirs
themselves. Plus
Maksim> these days alot of people use IDEs like Eclipse which have very nice
support
Maksim> for refactoring your code automatically and could easily have a tla
plugin take
Maksim> care of calling a "tla move" cmd for you (of course if I was using
taglines
Maksim> the IDE wouldnt have to know about tla, but I think I will stick with
explicit
Maksim> tags for the moment :-)
Maksim>
Maksim> Now Mark asked what problems get solved & what ones get created? well
as I
Maksim> see it problems solved are:
Maksim> 1. no "shadow" id files, as there are now, one for every file in
Maksim> the archive.
*But why is that a problem?*
Maksim>
Maksim> 2. if you go the "one big inventory file" route then no ".arch"
Maksim> control subdirs scattered across the whole src tree, which makes
Maksim> things much easier & faster for 3rd-party indexing tools like
Maksim> the one I'm working on (an alternative to revision libraries).
I'm somewhat at a loss why tla/arch should make life more difficult to
itself to make 3rd-party indexing tool writer's life "easier".
You'll note that CVS uses the infamous "CVS" subdirectory to perform a
similar function.
Maksim> 3. It gives you the ability to provide a programable interface to
Maksim> moving src files around - using those despised (as Tom put it
Maksim> :-) "tla add, move" cmds to 3rd party tools like IDEs (emacs
Maksim> included) rather then make them have to edit src files
Maksim> themselves to set a tagline when a new file is created for
Maksim> instance.
Absolutely NOTHING precludes you from using explicit tagging, where such
tools are required. Nothing precludes you from REQUIRING explicit tagging
for your no-doubt nifty toolset to work.
I'm rather annoyed at you attempting to remove a functionality that *I*
find very useful.
Maksim>
Maksim> 4. It allows people like me to write new tla-archive compatible
Maksim> clients to store the "working dir" however they like
Maksim> (eg. readonly).
Maksim>
Maksim> Problems to this?
Maksim> 1. well it does make data corruption easier, you put all your eggs
Maksim> in 1 basket so to speak, so if you stuff up the inventory its
Maksim> probably worse then stuffing up just on of the .id files
Maksim> 2. cant think of any others - but I'm sure others can...
EVERYONE MUST use "tla move" and relatives under your plan. Now we can opt
out of that crap if we wish.
You've just made a single point of synchronization when multiple people
update an archive at the same time.
Finally, when you use taglines you won't find .id files.
--
Mark A. Flacy
Any opinions expressed above are my own. Any facts expressed above
are, ummm, facts.
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec
"Any sufficiently advanced feature is indistinguishable from a bug."
-- Greg Alexander's corollary