From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Arik Mitschang Newsgroups: gmane.emacs.devel Subject: Re: pcvs branch and merge functions Date: Mon, 2 Aug 2010 16:46:11 -0400 Message-ID: <19543.11923.20328.257017@gargle.gargle.HOWL> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1280781562 715 80.91.229.12 (2 Aug 2010 20:39:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Aug 2010 20:39:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 02 22:39:20 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Og1n5-00020p-6a for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 22:39:19 +0200 Original-Received: from localhost ([127.0.0.1]:43807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Og1n4-0007Hu-F7 for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 16:39:18 -0400 Original-Received: from [140.186.70.92] (port=60949 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Og1mm-0007AO-4M for emacs-devel@gnu.org; Mon, 02 Aug 2010 16:39:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Og1mk-0003Ao-HE for emacs-devel@gnu.org; Mon, 02 Aug 2010 16:39:00 -0400 Original-Received: from mail-qy0-f169.google.com ([209.85.216.169]:53742) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Og1mk-0003AU-EX for emacs-devel@gnu.org; Mon, 02 Aug 2010 16:38:58 -0400 Original-Received: by qyk12 with SMTP id 12so26025qyk.0 for ; Mon, 02 Aug 2010 13:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:mime-version :content-type:content-transfer-encoding:message-id:date:to:cc :subject:in-reply-to:references:x-mailer; bh=ODY3LYD5GqyRwQPcIoF2/ecPsXmps4SbTlSItA81RIA=; b=DJS/DlSike9QAwKD5Ye6tIxM2uCzi64fcXxbBdCAH07BUpYV6ErOWGWi2EyJ7y09hZ h5byx4gMHaXof5mosEACSFb6vnzGb2W663QyqOvfVxDZJAJsZFg2E41krEklTbK34max YmYbpZtFXvVK6jayIrpBZgni0buOK9Pxj8WDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:content-transfer-encoding:message-id :date:to:cc:subject:in-reply-to:references:x-mailer; b=tU1d2TBAEVtAPGhinnlTO61WzBx+DF+GvrvrBDWhShMqzraN9BQUkK75FjzJeiVdiw ZDe6Xsgkb+C+W+0RmDmbpwGURclRPuWsD73Kc2KHGt1sJWmnLRLqlUdfli8OAJ1Vez3X Uo/72IGitLhQlslh5Z5agOL+8k3nTk74vxkwQ= Original-Received: by 10.224.115.32 with SMTP id g32mr2104693qaq.22.1280781536951; Mon, 02 Aug 2010 13:38:56 -0700 (PDT) Original-Received: from eromajin.arikm.com (c-71-233-149-191.hsd1.ma.comcast.net [71.233.149.191]) by mx.google.com with ESMTPS id r1sm526777qcq.22.2010.08.02.13.38.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 13:38:56 -0700 (PDT) Original-Received: by eromajin.arikm.com (Postfix, from userid 1000) id 2788E11E293; Mon, 2 Aug 2010 16:46:11 -0400 (EDT) In-Reply-To: X-Mailer: VM undefined under 23.2.1 (x86_64-unknown-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:128162 Archived-At: Hi Stefan, Thanks for taking a look, and the comments. > - why cvs-branch-tag-branch-postfix? I mean if I name the branch "foo", > I don't want Emacs to rename it to "foo-BRANCH", do I? I think it depends. We very likely want to name the branch point as "BASE" or something, and some like to use "MERGE" for the merge result. I use both so I then like to be annoyingly explicit and say "BRANCH". This can of course be defaulted to nil if most do not like that behavior. > - ("\C-m" . cvs-mode-merge) binds it to RET (since it's the same as > ^M), which is already used for something else. ah yes, perhaps they could be bound to \C-c\C-m and \C-c\C-b for merge and branch respectively? (or not at all, these are probably not the most regular commands) > - I wouldn't bother supporting the case where > cvs-branch-tag-base-postfix is nil. Because we should never branch in CVS without tagging the base? (I agree, but it doesn't seem to harm since it is a custom variable anyway. Might just want to warn about the danger of a nil setting in the description) > - cvs-mode-merge should provide completion of branch names. > Otherwise you might as well use C-u M-x cvs-mode-update and type > the -j yourself. True, a little more typing but I see your point. > - I think > > (if (and (not (equal branch-tag merge-tag)) > (not (null cvs-branch-tag-merge-postfix))) > (cvs-mode-run "update" (list "-j" branch-tag) fis) > (cvs-mode-run "update" (list "-j" branch-tag) fis)) > > is equivalent to > > (cvs-mode-run "update" (list "-j" branch-tag) fis)) Indeed so, that must be leftover from attempt at merge tagging, but that of course was the totally wrong place for that. > BTW. Maybe an even better option would be to provide completion after > "-j" and "-r" when you do c-x M-x cvs-mode-update. You mean than the cvs-mode-merge/branch functions all-together? I think it's nice even if a little redundant to have the merge function just in case one is having trouble which switch to use. For the branch function this wouldn't be sufficient since we need several operations including tagging, which I can never remember the switches/order for, but cvs-mode-branch is quite obvious. > - You might be able to move the -MERGE tag automatically by creating > (at the end of cvs-mode-merge) a special file in the CVS admin dir > which would hold some info about the result of the merge, and then in > cvs-mode-commit you can check this file to see if the commit is > committing the result of the merge or something else. Maybe the > simplest way is an empty file, and upon commit you simply ask the user > (if the file is present) if he's committing that merge. I will mess around with this when I get the chance. Thanks again. I will post a diff with the new version when I get to these updates and have a working version. ~Arik