From: Zenaan Harkness <zen@cashpoolcomps.com>
To: arch <gnu-arch-users@gnu.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099112721.17184.70.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Sat, 30 Oct 2004 15:05:21 +1000
Subject: [Gnu-arch-users] per-user =tagging-method
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2040
Lines: 50
This is very similar to Aegis functionality (I spent quite a few years
on Aegis).

Aegis allowed per-project (per-archive) as well as per tree (working
dir/tree) tagging method (and various other things). It was basically
cascading config - working dir (change), then project (archive).

I need something slightly more flexible again - per-user tagging method.

The reason is, my windows guy uses rsync to sync with his laptop.

This means he doesn't get rm's and mv's of SCMed files.

So he star-merges a change that rm's or mv's, which is fine, rsyncs back
to his laptop, which is fine, makes changes on laptop, then rsyncs back
to Unix working tree, which is not fine, since rsync says "oh, this file
(with older timestamp) doesn't exist on target/server, I guess I better
copy it across", which is obviously _not_ fine.

However, if he had a custom tagging method that rejected commits when
homeless .java (source) files are lying around, he would know to go and
delete the orphaned file(s) from both his Unix home dir, as well as his
Windows laptop, and away he goes...

I really don't want to change the tagging method for myself, since I
make liberal use of symlinks to make it easy for me to get to source
files within our not-particularly-shallow Java source tree hierarchy. I
also on occasion have an actual source file lying around temporarily,
and I don't want to have to keep manually moving it out and into my
tree, just to be able to do my intermediate commits.

Such a feature would require a ~/.arch-params/=tagging-method, used in
precedence to project/archive tagging method. And I guess some will
vehemently argue against this. To fend off such arguments ahead of time:
it would of course be optional.

May be per-user-per-project (strongest/highest override) - even greater
flexibility :)

cheers
zen


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/