Also note that the given chmod command will change archive file permissions
as well. The command should at most be "find /cvsroot/project -type d |
chmod 770".
Also, if one is using file system ACLs, chmod g+s may not be enough if the
user isn't in the directory's group. One would really have
[EMAIL PROTECTED] |
| cc: [EMAIL PROTECTED], (bcc: Noel L Yap) |
| Subject: RE: How well does CVS handle other types of data? |
>|
[ On Fri
>If you want to turn automated merging off (either globally or on a
>per-file basis) in CVS then you must first define a mechanism for
>telling CVS when a manual merge has been completed (without any
>remaining conflicts, of course). This is easy for the case of
>concurrent edits, and harder for
>[ On Friday, July 13, 2001 at 13:11:56 (-0400), Noel L Yap wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>>
>> That's right. You won't have problems with binary files in CVS 'cos they're
not
>> in CVS. This does
>[ On Friday, July 13, 2001 at 11:00:40 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>>
>> >Indeed as the above quoted documentation hints the initial introdcution
>> >of '-kb' to RCS itself was also primarily
>Aegis doesn't guarantee no bugs. It simply requires a new test for
>every change and re-runs all the old tests, as well as the new test, on
>the submitted new code before it can become the baseline.
>
>If the rest of your process is "working" then no bugs will ever be
>re-introduced. If the ch
>That's a moot point Steve. If your build system (makefiles, scripts,
>source to tools, etc.) is also checked in to your CVS tree then it will
>be tagged and you can "cvs checkout; make" and you'll still ``get
>_everything_'' but you won't have *any* problems with binary files in
>CVS!
That's r
>While the ability to use CVS to do merges of branches is but one
>advantage of CVS, the need of CVS to do merges on a regular basis is one
>of the requirements it has on the data it manipulates.
This situation can be avoided (not prevented) with proper procedures.
>Indeed as the above quoted d
>> Why, in the name of Babbage, is that supposed to be better? I still
>> can't automatically merge binaries, so it's no advantage there. So
>> what do I get if I do that?
>
>but you can't avoid having to do something equivalent to merging of
>opaque format binary files with CVS!
You can if yo
>CVS is not, by itself, a configuration management system any more than
>it is a build system. It does have several very important features that
>allow it to facilitate CM though...
Yes, but it is a version control system. That's what wer'e talking about here.
Noel
This communication is fo
>[ On Thursday, July 12, 2001 at 20:51:00 (-0400), Noel L Yap wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> The key word here is avoid, No system can ever prevent concurrent edits.>
>
>Huh? If there's no branching support, and
To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: Need to F
>> From: Lan Barnes [mailto:[EMAIL PROTECTED]]
>>
>> I really fail to see the technical reason for deprecating using CVS
>> archives to store -- and tag -- binaries necessary for a build. The
>> disk space involved is a nonissue for us (space is cheap), and the
>> issue of avoiding simultaneous
This is one reason I use the terminology "non-mergable" instead of "binary". In
no way are the two related.
Noel
Hi everybody,
As I saw a lot comments on this thread, perhaps her is it a nice solution ...
So here just a suggestion (if you have big disk space and powerful server), it's
to conv
>Concurrent editing in the sense that phrase is most commonly used with
>CVS is not the only, or even the major, problem here! This issue can
>much more easily be avoided by external task management.
>
>Merging of branches (which is a totally different form of concurrent
>editing that's not nece
PM |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject:
04:07 PM |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: RE: How well does CVS handle
I had meant to say that source code is not CVS-mergable in the strictest sense
of the word.
Noel
Not only that, but CVS does't handle code reformats elegantly at all.
Philosophically, this means that CVS can't merge source code under all
conditions. Does this mean you shouldn't use it when such
Not only that, but CVS does't handle code reformats elegantly at all.
Philosophically, this means that CVS can't merge source code under all
conditions. Does this mean you shouldn't use it when such tasks can occur? Of
course not, All it means is that these situations need to be controlled so t
nd to |
|| info-cvs |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
|
PM |
|| |
|+-->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: (n
| AM |
|| |
|+->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: C
PM |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: CVS for student shared
To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: Re: repo
PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: Re: commit message fails|
>|
I
>> -Original Message-
>> From: Kostur, Andre [mailto:[EMAIL PROTECTED]]
>> > -Original Message-----
>> > From: Noel L Yap [mailto:[EMAIL PROTECTED]]
>> >
>> > CVS only requires files to be mergable. This has a different
>>
PM |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED], [EMAIL PROTECTED] |
| cc: [EMAIL PROTECTED], (bcc: Noel L Yap) |
| Subject: RE: Future CVS De
pjb |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
| cc: [EMAIL PROTECTED], (bcc: Noel L Yap) |
| Subject: Re: Future CVS De
>As I just mentioned in another somewhat related thread anyone and
>everyone is "free" to design and implement a replacement for CVS. If
>such a thing actually succeeds in replacing CVS then that's an
>achievment to be applauded. In the mean time CVS does a fair job at
>what it's been designed
>Of course not. CVS was not designed to handle unmergeable files. Ergo
>your argument is meaningless within its context. RTFM.
But CVS+process can handle non-mergable files.
>Most importantly it's not even conceptually possible to a concurrent
>versioning system on primarily non-mergable fil
PM |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED]|
| cc: [EMAIL PROTECTED], (bcc: Noel L Yap) |
| Subject: RE: Future CVS De
CVS only requires files to be mergable. This has a different meaning from
requiring files to be non-binary.
One thing that may be done is to add a hook for pluggable diffing/merging
engines.
Noel
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Mon
>1. Must be able to work with Patrol, JAVA, C, C++, SQL scripts
I don't know what Patrol is.
In practice, there's more renames and moves in Java than in other languages.
These ops are a pain in CVS.
I've seen no problems with other file types.
>2. Access to source controlled thru policies s
>> I beg to differ. Even in your preferred method, you rely on the user
>> to carefully leave a bread crumb trail, by noting the rename in the commit
>> comment.
>
>The audit trail is not necessarily dependent on the user -- there are an
>almost infinite number of ways to mechanise and automate
>> Or how 'bout using the edit and commit patches that more or
>> less give you
>> advisory locks. I'm thinking you may also want to add (if
>> it's possible without
>> breaking something like client/server) a server-side config
>> that would make
>> these flags a default.
>Now there's the rub.
>1) The exclusion of any sort of authentication capabilities in CVS. In the
>case of local CVS (where "local" also includes rsh and ssh. They're just
>hiding that they're actually running on the repository server), CVS assumes
>that the userid associated with the login is reliable. This I thi
06/18/01 |
|| 04:25 AM |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED], [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
|
>I am trying to do an mandatory like using the a tag, thought the brach
>tag exist, I get the following msg.
>cvs admin -lBRANCH_5_10 test.cc
>RCS file: /nfs/eagles/export/home/jeeva/mycvs/src/Attic/test.cc,v
>cvs admin: /nfs/eagles/export/home/jeeva/mycvs/src/Attic/test.cc,v:
>branch BRANCH_5_1
I've heard from an employee of one large financial institution that they use CVS
on a level of at least hundreds of developers, but I don't think I'm at liberty
to mention names. I can say, though, that it is not JPM.
Noel
Does anybody know about name of big companies using CVS?
-Shailesh
--
| 08:39 |
|||
|+>
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: Preven
| info-cvs;|
|| Please |
|| respond to |
|| Ray.Oneal|
|| |
|+--->
>|
|
| Please respond to hwong|
|| |
|+->
>|
||
| To: [EMAIL PROTECTED]
>I have search the archives and I know that locking files has been
>brought up in the past. According to the manual, -l will lock the
>latest revision number. But, in the next paragraph it states that I
>need to use rcslock.pl to have a reserved checkout. I am confused on
>what exactly the -l
>I visited there but after your first letter. But it was probably due my
>illitteracy or alike that I couldn't connect RCVS (project that was
>marked to be in "planning" state) to your patches. BTW. What is/will be
>the difference between RCVS sources and sources in cvshome.org? RCVS
>seemed to h
>We have at NRC one group that needs to lock certain files (binary ones)
>RCS way although they are using CVS as version control system. For this
>reason I have applied (as they requested) to our CVS 1.10.8 version your
>edit-c.diff patch to enable edit -c (and -f) option. I'd like to upgrade
>o
>Some of the patches Noel mentioned are intended to prevent two non-determined
>users from editing the same file at the same time. The editor information is
>also available to anybody using the 'cvs watchers' command.
Technically, it's the 'cvs editors' command although those editing the file a
:00 |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: Information about multiple
CC's reserved
and unreserved checkouts, but I don't know of something like a watches feature
within CC (short of implementing it yourself with attributes).
Noel
--- Noel L Yap <[EMAIL PROTECTED]> wrote: >
Forgive me if I still think you're crazy.
>
> I see
Forgive me if I still think you're crazy.
I see two ways to attack this:
1. Get permission from your company to use CVS for such projects.
2. If you're keeping a separate repository at your site with no outside access,
why not just use ClearCase? Whether or not you're using CVS, you'll still b
I haven't been following this thread so forgive me if I repeat anything.
Along with standard file system permissioning, you may want to see if your file
system supports ACLs (man setfacl and getfacl for more info).
Also, if you use SSH, you can limit the server to CVS access only (see SSH docs
o
I don't understand your post. Can you elaborate?
I've been able to use SSH to limit access to CVS only. Is this what you're
asking?
Noel
Well, this looks like a FAQ. But searching the site for
"secure shell" wasn't 100% rewarding. With a search to
"restricted cvs shell" google brought up
:54 |
|||
|+>
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: patche
:26 |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject:
Why not just turn off permissions in the repository?
Noel
Hello !
I have a question regarding the 'cvs admin -l' - command.
If I try to lock a certain file and passing the command
a certain Branch-Tag, cvs doesn't lock, and gives the
following error-message:
RCS file: .../file.C,v
cvs admi
PROTECTED]|
| cc: (bcc: Noel L Yap)|
| Subject: RE: clean, updated patches on SourceForge |
>|
Most of the
| 05:03|
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED]|
| cc: (bcc: Noel L Yap)|
| Subject: RE: clean, update
I've cleaned up and updated my patches on SourceForge. The most commonly
requested of these patches are for reserved locks. Once again, these patches
won't make it into the "standard" release unless someone(s) updates the docs and
the tests. Unfortunately, I don't have the resources to do this.
-
Do I need to install the patches "edit -c" and "checkin -c" before the edit
fail will work ?
I've tried the "cvs watch on" method but it still allows another user to do
a "cvs edit" ie it does not fail when I've tried to check it out as another
| 2001.05.02 22:04 |
|| |
|+--->
>|
||
| To: [EMAIL PROTECTED], [EMAIL PROTECTED] |
| cc: [EMAIL PROTECTED], (bcc: Noel L Yap) |
| To: [EMAIL PROTECTED] |
| cc: (bcc: Noel L Yap)|
| Subject: cvs locking and watching... |
>-
t contact
other editors for any reason.
Noel
[EMAIL PROTECTED] on 2001.05.02 06:11:14
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Noel L Yap)
Subject: RE: Reserved checkouts.
Members Equity Email System
But I do need to use reserved checkouts - I have examined the issues for and
[EMAIL PROTECTED] on 2001.05.02 10:21:54
>What you want is some way of controlling who's working on the
>file at any given time, and the CVS way to do that is to set
>"cvs watch on" all files that you want to control, and ask
>the developers to use "cvs edit" to unlock them. This isn't
>stric
ou want them.
You'll only "need" to use reserved checkouts if your developers refuse to stick
to procedures.
Noel
[EMAIL PROTECTED] on 2001.05.02 06:11:14
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Noel L Yap)
Subject: RE: Reserved checkouts.
Members Equity Email
Or, if you're going to modify anything, you can add a CVSPATH ev that's a
generalization of CVSROOT.
Noel
[EMAIL PROTECTED] on 2001.05.01 16:56:42
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Noel L Yap)
Subject: Re: modified cv
Have you checked to see if your file system supports ACLs? If it does, you can
use them to manage the permissioning.
Noel
[EMAIL PROTECTED] on 2001.05.01 09:42:46
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: modified cvs
I have to manage more than 16 project and i have to
[EMAIL PROTECTED] on 2001.04.12 14:34:33
>> "Mike" == Mike Castle <[EMAIL PROTECTED]> writes:
>
> Mike> On Wed, Apr 11, 2001 at 06:06:22PM -0700, Paul Sander wrote:
> >> - If a branch is merged multiple times to an ancestor, don't count
> >> the result of the prior merge as a conflict. (R
[EMAIL PROTECTED] on 2001.04.12 13:31:41
>On Thu, Apr 12, 2001 at 11:29:59AM -0400, Noel L Yap wrote:
>> [EMAIL PROTECTED] on 2001.04.12 11:14:55
>> >I thought we were talking about a generic tool that would do a merge for
>> >any arbitrary file and save it to d
[EMAIL PROTECTED] on 2001.04.12 11:14:55
>On Thu, Apr 12, 2001 at 11:05:51AM -0400, Noel L Yap wrote:
>> If a wrapper tool were used, it would necessarily have to munge around the
>> CVS/Entries file which is supposed to be internal to CVS (eg its
implementation
>> cou
[EMAIL PROTECTED] on 2001.04.11 21:31:01
>On Wed, Apr 11, 2001 at 06:06:22PM -0700, Paul Sander wrote:
>> - Invoke a type-specific merge tool, ideally one of the user's choice.
>
>Actually, simply "an external tool. Period" would be sufficient. Then
>said external tool can have whatever inte
In the future, please email the list and supply a subject.
Your choices are (assuming the server is on Unix):
1. Use groups to control who has access to what.
2. Use file system ACLs to control who has access to what.
Please see my previous email for details.
Noel
[EMAIL PROTECTED] on 2001.
rther.
> 4. Use pserver. I'm not too familiar with this approach but
> I've never run into
> anything the above doesn't cover.
>
> Noel
>
>
>
>
> [EMAIL PROTECTED] on 2001.04.10 08:44:55
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Noel L Yap)
> S
t cover.
Noel
[EMAIL PROTECTED] on 2001.04.10 08:44:55
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Security issues
Hello list,
now I have my CVS infrastructure growing bigger, several
departments are using it, and aparently there is requirement
for security. I need to restrict depar
Take a look at http://www.enteract.com/~bradapp/acme/branching/.
Noel
[EMAIL PROTECTED] on 2001.03.26 22:36:36
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: branching/development strategy
I was hoping this would be discussed on this list but I haven't seen it yet.
Whe
stays the
same.
Noel, if there's anything I can do to help get these patches into the main
distribution, then feel free to drop me a mail.
-Original Message-
From: Noel L Yap [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 4:37 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED
, what exactly are you still left with there? I do not have much free
time, but a little that I have I would be willing to look at whatever is
left outstanding. I need to see how much is left before I can tell you if I
can take it on or not.
have a day,
Sasa
-Original Message-
From: N
[EMAIL PROTECTED] on 2001.03.24 14:18:20
>I am watching the thread of "split for rcvs" and "locking and other patches"
>and I must say that I am quite shocked.
>
>Why is that the requirements for sending the patches are getting more hard
>every day?
I think these preconditions have existed f
[EMAIL PROTECTED] on 2001.03.23 14:25:36
>> Since I didn't found RCVS, I'm strictly speaking from what I saw. At the
time
>> RCVS was created, maintenance on CVS was questionable. The product had been
>> handed over from one company to another. I think the founder wanted some
place
>> that
Are you sure you're not using a Windows version that's been patched?
Noel
[EMAIL PROTECTED] on 2001.03.23 01:39:59
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: feature question
Clear DayWhy did not 'edit -c' make it to the cvs 1.11 and yet it is on th
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Noel L Yap
Sent: Thursday, 22 March 2001 12:34 p.m.
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: reserved lock and other patches
My free time has run out again. The stuff I still need to get done are:
1.
Derek R. Price" wrote:
> Noel L Yap wrote:
>
> > >I'd also want to see documentation updates (to cvs.texinfo) before I'd
check
> > this
> > >in.
> >
> > It looks like cvs.texinfo is easy enough to change, but can you tell me how
I
>
I think it just uses diff3.
Noel
[EMAIL PROTECTED] on 2001.03.19 12:42:26
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Merge algorithm
Hi!
I got another question...
Is the merge algorithm used by CVS documented somewhere?
I would really appreciate if someone could point
[EMAIL PROTECTED] on 2001.03.15 14:13:12
>> I remember testing for these situations when I originally made the patch.
>> Nothing horrendous (ie crash or hang) happens, but I don't really remember
>> exactly what happens (eg warning message, no message, ...).
>
>I think I'd want the commands to
No, it doesn't. But you can easily use file system ACLs to do what you want if
your file system supports them (man setfacl for more info).
Noel
[EMAIL PROTECTED] on 2001.03.15 05:16:31
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject:
[EMAIL PROTECTED] on 2001.03.15 08:44:37
>Are these patched backwards/forwards compatible? i.e. what happens when the
>client and server are out of synch on any of these patches?
>
>ME = multiple_edits, R = reservations, MER = multiple_edits+reservations, ! =
not
>present (pre-patch):
>
>
I'm using cvs-1.11.
I have a branch checked out and doing an annotate on a file:
cvs ann src/commit.c
but it's not showing lines that've been checked into the branch. However:
cvs ann -r enh-multiple_edits src/commit.c
does work.
Is this by design. It's a bit counter-intuitive to me.
Noel
rs
will report nothing being edited.
Noel
[EMAIL PROTECTED] on 2001.03.07 18:04:49
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: bug: cvs editors
"cvs editors" will not report edits created by specifying pathnames. For
example:
cvs edit src/Makefile
cvs editors
cd src
hich will have both of the above (minus merge
conflicts, of course).
If anyone has a better suggestion, I'd like to hear it.
Thanks,
Noel
[EMAIL PROTECTED] on 2001.03.06 18:55:36
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: reserved lock and other patches
I'm finally
"cvs editors" will not report edits created by specifying pathnames. For
example:
cvs edit src/Makefile
cvs editors
cd src
cvs editors
will report nothing being edited on each invocation of "cvs editors". Note
that:
cvs edit src/Makefile
cvs editors src/Makefile
cd src
cvs editors Makefile
rep
I'm finally spending some time cleaning up my patches available on
sourceforge.com under project RCVS. I have a RFC about organising some of the
bigger enhancements. I see the following as the two biggest enhancements:
1. Users are allowed to edit files multiple times. The edit information is
c
Ahh, I see the problem. You need some way to tell everyone that the database
stuff is being worked on. You're thinking of using CVS as the mechanism to do
so. I think I would use the "cvs edit -c" patch for this situation.
Noel
[EMAIL PROTECTED] on 2001.03.02 13:54:59
(see below)
> [EMAIL
communication--editing source code could be a direct form of communication
itself! Perhaps this is the future for concurrent development. (?)
Can anyone relate anything about using this for concurrent development
with CVS?
Tim S.
- Original Message -
From: "Noel L Yap" &
[EMAIL PROTECTED] on 2001.02.28 12:30:31
>Some things can't be easily versioned under CVS. For example, PL/SQL or
>other code that lives in the database. Since it's a shared resource, we need
>to do exclusive locking to version it.
Is there a way to export/import these files as text? If so,
EMAIL PROTECTED] on 2001.02.27 18:24:21
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Re: "Concurrent" VS...
Hi list,
I have had to explain this to many people that ought to know better, so I'm more
than happy to perform the routine for an audience that might be forgiv
CVS.
Noel
[EMAIL PROTECTED] on 2001.02.16 17:31:53
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Interaction between cvs co and edit watches
We are using a CVS pserver model with Linix Server and NT clients. We are
running CVS v1.10.8.
I have discovered that using cvs co to checkout
The problem with overloading "cvs add" to create new modules is that one of "cvs
add"'s preconditions is that the module already exists. I can understand
requests like having "cvs add -r" to recursively add down a directory hierarchy,
or "cvs add -p" to recursively add up a directory hierarchy, b
It sounds like you're using some sort of content management software. I'm not
100% decided on this issue, but I'm currently leaning towards the idea that
content shouldn't be versioned the same way normal files are since they tend not
to be files.
I guess the ultimate problem is that a set of to
[EMAIL PROTECTED] on 2001.02.16 14:50:13
>Another possibility introduces an extra step for everybody, but basically
>allows concurrent development. In that model, developers work in their own
>workspaces then copy files that need testing into the public area or check them
>in and have a check
[EMAIL PROTECTED] on 2001.02.16 10:13:39
>I understand that's the way CVS was designed for multiple
>developers. However for some reasons, we want to have the
>reserved checkout on the files been updated. The file types
>we have include text code, word documents, executable binaries,
>package
[EMAIL PROTECTED] on 2001.02.15 18:54:02
>We are using CVS for CM. It came with a problem that multiple developers
>were updating
>a same file. Although cvs provides lock/unlock commands, it seems not
>convenient.
CVS is meant to allow concurrent checkouts; that's what the C in CVS is for.
>
(bcc: Noel L Yap)
Subject: cvs add --new
I like Rex's idea of creating a new way to add
a new directory (and contents) to the repo.
I do this all the time; "Import" is typically not
what I want to do, and I haven't yet written a
wrapper script to perform this sequence of act
1 - 100 of 612 matches
Mail list logo
