unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Ludwig, Mark" <ludwig.mark@siemens.com>
To: Barry OReilly <gundaetiapo@gmail.com>,
	help-gnu-emacs <help-gnu-emacs@gnu.org>
Subject: RE: Switching branches and TAB
Date: Thu, 30 May 2013 22:59:48 +0000	[thread overview]
Message-ID: <BC5672F8AD4C054BAF167C9801500D1ABCB3D1ED@USSLMMBX003.net.plm.eds.com> (raw)
In-Reply-To: <CAFM41H0rK8uE6DCK0s+GSXUQkGJwCY04gss2ZSCe_=_JchAQ9Q@mail.gmail.com>

> From: Barry OReilly, Thursday, May 30, 2013 2:48 PM
> 
> > I am using ClearCase as a source control and emacs for eshell. If I pick
> a view
> > (similar to changing branches) before launching emacs&, when I am typing
> a file
> > path in eshell, i can press tab to finish the path name for folders and
> files.
> > However, if i launch emacs& and then set the view, the ability to press
> tab to
> > finsih the path name does not work for some files. This also occurs when
> > setting to a different view in eshell.
> >
> > So whenever I would want to change views, I could start up a new emacs&
> to
> > avoid this problem. Is there someway around doing this?
> 
> I'm also in the unfortunate position of using that atrocity of a VCS.
> 
> When you set dynamic view, a new csh-like shell is started. If you started
> Emacs before that, it forked from the parent shell so has no visibility of
> the new shell. You could run xterm&, set view, switch to the new xterm and
> find you won't see your view's files for the same reason.
> 
> I wouldn't expect any issue in snapshot views.

I also use ClearCase, frequently have several dynamic views open
concurrently, and may have an instance of Emacs for each.  In my case,
this feels natural, because I have a complete context in the view, so
it feels natural to have a unique instance of Emacs in that view too.

For example, I frequently run hours-long builds ("compiles")
concurrently in these instances of Emacs.  One instance couldn't do
that (only one "*compilation*" buffer without more customization than
I feel would be good to do, not to mention losing everything if that one 
Emacs were to crash).

It probably helps that the way we refer to files involves
environmental variables (one per "module" of this large software
system), each of which having a definition starting with /vobs/....
Sure, I can use /view/foo/vobs/... when I need to work across views,
but I rarely need to do that.  In a real sense, each view represents a
"project" I'm working on.

At the moment, I have 18 views active (each in its own xterm) with 12
instances of Emacs running (not running Emacs in 6 views).

[[ I find ClearCase more powerful than most other source code
   management systems.  This could be because of the customization we
   have that manages queues of sets of changes -- dozens of queues,
   one for each of the multiple releases of the products and each of
   the customer-specific maintenance versions that we concurrently
   maintain.

   It uses a hierarchy among all of these with a good deal of
   automation around merging.  The semi-automated merging makes sets
   of changes flow among the queues, making it easy for the engineers
   to remember to propagate changes in the "forward" direction among
   releases until hitting the end.  Along with the formalized review
   process before leaving a queue, this helps ensure that
   customer-specific maintenance gets generalized and incorporated
   into the "latest and greatest" version of the product.

   Each of my personal views has an associated branch where I do my
   project work, and for our concurrent development on half a dozen
   platforms, I use up to half a dozen different views per branch for
   each platform's build of that branch (if there is platform-specific
   stuff I need to worry about, or if I want some particular
   compiler's scrutiny such as using GCC on Linux for its ability to
   warn when printf-style format strings aren't matched with the data
   arguments).  ]]

Cheers,
Mark




  reply	other threads:[~2013-05-30 22:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30 19:47 Switching branches and TAB Barry OReilly
2013-05-30 22:59 ` Ludwig, Mark [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-05-31 15:41 Barry OReilly
2013-05-30 15:57 berk.dev
2013-05-31  5:14 ` Kevin Rodgers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BC5672F8AD4C054BAF167C9801500D1ABCB3D1ED@USSLMMBX003.net.plm.eds.com \
    --to=ludwig.mark@siemens.com \
    --cc=gundaetiapo@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).