Kai Maybe `::' could be the end of the connect list?
Maybe nobody uses VMS and DECNET anymore, but isn't "::" a separator
between host and path components in a DECNET address? (It's been a
*long* while since I've seen a VMS system...)
It's also a separator for Mac file
On Wed, 28 Feb 2001, Francesco Potorti` wrote:
Kai Maybe `::' could be the end of the connect list?
Maybe nobody uses VMS and DECNET anymore, but isn't "::" a
separator between host and path components in a DECNET address?
(It's been a *long* while since I've seen a VMS
On 28 Feb 2001, Kai Grojohann wrote:
On 28 Feb 2001, Daniel Pittman wrote:
Well... I bow to Kai on this. My personal feeling is that having a
branch for the new development and retaining the older tramp for
bug-fixing 'til the new one works is good.
I prefer to have the development be
On 28 Feb 2001, Daniel Pittman wrote:
Unless the '::' is actually significant in a host name or a user
name, I don't think there will be problems.
Right. So, is there a host name or a user name in any kind of naming
scheme which contains "::"?
And this is a variable anyway, so we can still
On 27 Feb 2001, Kai Grojohann wrote:
On 27 Feb 2001, Daniel Pittman wrote:
This is a description of what I have implemented and working in the
path parser at the moment, modulo ensuring that it all works. The
optional-ness of things is somewhat vague at present.
This is way cool. Mouth
I'm afraid something might need to be done to allow filenames with `:'
on them (on the remote host). Hm.
Maybe `::' could be the end of the connect list?
Another idea for `/!:' is `/tr:' which I guess also works on Windows.
But `/!:' is also nice.
Before putting this out,
Daniel Er, yes. Does Emacs even support DECNET systems these days?
If some version of Emacs runs on OpenVMS I wouldn't be surprised to find
that some DECNET support is available.
Daniel Anyway, I don't understand DECNET. Is the '::' part of a
Daniel distributed file path when used,
"Daniel" == Daniel Pittman [EMAIL PROTECTED] writes:
like? On a branch, of course, because a non-working version as the trunk
would be /very/ bad. :)
Why would it be bad ?
Just make sure there is a `stable' tag pointing to the last working
release and you're set.
Stefan
On 26 Feb 2001, Kai Grojohann wrote:
On 26 Feb 2001, Daniel Pittman wrote:
Once it got there, I figured that establishing a branch in CVS and
committing it, then porting the various file operation handlers to
the new infrastructure was in order.
I am happy to listen to suggestions for
Branches are not pure evil, but I'd recommend against using them in
this case, because they will probably bring more hassle then they
deserve.
I think branches are a problem for small development teams. Since the
Tramp development team is very small (a quarter of a Kai plus Daniel),
What else do you suggest as to feature versus bugfix releases?
Stefan Just mix the two, like most/every other Emacs package. New
Stefan releases have their share of bug fixes, new features and new
Stefan bugs.
Agreed. I think separating bug fix and new feature releases is
I'm thinking that it's about time now to do something about
stabilizing Tramp. Up to now, there has only been one branch in its
development, so you never knew whether you were getting bug fixes or
new features.
I'm thinking that this might be a good time to change the revision
number to 2, and
"Kai" == Kai Grojohann [EMAIL PROTECTED] writes:
I'm thinking that this might be a good time to change the revision number to
2, and to create a STABLE branch on CVS. Then people can start to implement
new features in the head branch without impacting the users.
Branches are not pure evil,
On 24 Feb 2001, Stefan Monnier wrote:
Branches are not pure evil, but I'd recommend against using them in
this case, because they will probably bring more hassle then they
deserve.
I think branches are a problem for small development teams. Since the
Tramp development team is very small (a
14 matches
Mail list logo
