[Gnu-arch-users] Re: tagging-method explicit implementation

[Maksim Lin]

Yes, yes & yes.
I have been thinking the last couple of days about exactly the same thing.
I completely agree that move operations are pretty infrequent, at least in Java
programming (which is what I'm familiar with these days). In fact most movement
is done when you refactor your code, which would normally involve moving files
around to different directories rather then moving whole dirs themselves.  Plus
these days alot of people use IDEs like Eclipse which have very nice support
for refactoring your code automatically and could easily have a tla plugin take
care of calling a "tla move" cmd for you (of course if I was using taglines
the IDE wouldnt have to know about tla, but I think I will stick with explicit
tags for the moment :-)

Now  Mark asked what problems get solved & what ones get created? well as I
see it problems solved are:
1. no "shadow" id files, as there are now, one for every file in the archive.

2. if you go the "one big inventory file" route then no ".arch" control subdirs
scattered across the whole src tree, which makes things much easier & faster
for 3rd-party indexing tools like the one I'm working on (an alternative to
revision libraries).
3. It gives you the ability to provide a programable interface to moving src
files around - using those despised (as Tom put it :-) "tla add, move" cmds
to 3rd party tools like IDEs (emacs included) rather then make them have to
edit src files  themselves to set a tagline when a new file is created for 
instance.

4. It allows people like me to write new tla-archive compatible clients to store
the "working dir" however they like (eg. readonly).

Problems to this?
1. well it does make data corruption easier, you put all your eggs in 1 basket
so to speak, so if you stuff up the inventory its probably worse then stuffing
up just on of the .id files
2. cant think of any others - but I'm sure others can...

But I think the advantages of this approach alone make it worth investigating
at least - I'm in the middle of coding up some of these ideas - I'll post them
up for people to try once I have things reasonably stable (until I do just 
consider
these ramblings under the usual "free advice" column...)

And while we are on the subject of tags, could someone explain where exactly
tla uses them? Is it only for the merge/patch process?
I seem to keep seeing mention of how it allows you to maintain the history of
a files across moves/renames - but where exactly does tla track file history?
since I remember Tom asnwering that tla currently didnt have a cmd to get a
specific files patch history when I asked about it a while back.

Maks.


Bruce Stephens wrote:

> Robert Anderson <address@hidden> writes:
> 
> [...]
> 
>> From the implementation side, it seems like a pretty slick method to
>> me.  If you move a directory, all the corresponding moves "just
>> work" with the current method - no manual bookkeeping.
> 
> For a directory, yes.  How often does that happen?
> 
>> What you're proposing - some sort of textual inventory in {arch}, I
>> guess - would require the implementation to go through and keep
>> track of all of that movement and all the implications of directory
>> moves, etc.  Why do that when the filesystem already does that work
>> for you?
> 
> Because (while arch is still gaining mindshare) I can't justify adding
> taglines.  Because (in general) moving files (or moving directories)
> is unusual enough that I don't mind remembering to tell arch (or
> OpenCM, or subversion, or meta-cvs, or whatever).
> 
> [...]
> 
>> I think you're being a little bit glib about dismissing these things
>> as "just convenience."  After all, SCM - as well as any programming
>> tool period - is "just convenience."
>>
>> The really compelling thing about  taglines or internal tags is that
>> source  controlled file  movement is  then transparent  to ancillary
>> tools (as well as the  user himself.)  Plug-n-play.  No tweaking, no
>> rewrites.  Want to use your  favorite gui file manager to move stuff
>> around?  No problem.
>>
>>   But the
>>> implementation of explicit (both in explicit and tagline tagging
>>> methods) is just horrible---it's not just that ext2 filesystems don't
>>> do small files efficiently, it's that the implementation is just
>>> wrong.
>>
>> Can you explain what is "wrong" about it?  You seem to not like the
>> presence of .arch-ids dirs, and are concerned about disk space.  Is
>> that it, or is there something else as well?
> 
> I don't care about disk space.  I care about the impact in changesets.
> I care that if I'm trying to track sources from outside (say, CVS
> sources), then for those files that I think I might want to move, I'd
> better explicitly tag them first.
> 
> More generally, I care that systems in general seem to assume explicit
> management of such properties, and that that doesn't seem to do them
> any harm.  Arch is trying to do better (for which it deserves credit),
> but it requires modifying the files to do it, and I think that that
> mostly won't happen.
> 
> I think that renaming files and directories is unusual enough that a
> system ought to be able to cope with it with special commands, but
> without modifying files (adding taglines) or adding tag files (neither
> of which is likely to be useful to any other system).
> 
> I think the support is basically there for what I think ought to be
> there.  I think Tom has been too keen on taglines, and has
> deemphasized the implementation for anything else.
> 
> [...]
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>