Re: Feature request/ideas

[Frank Hemer]

On Saturday 05 March 2005 00:15, Derek Price wrote:
 Derek Price wrote:
  Mark D. Baushke wrote:
  | Therefore, I suppose that there could be a need for .origin to be
  | the first revision on TRUNK
 
  This would seldom mean much across multiple files, so I still think
  .origin should not be used.  The case Frank cited, where he is
  basically trying to diff against an import (thought not generated
  using the import command), is the only one where all the .origin
  revisions will be related in a sensible way, and even then only if no
  files have been added or removed on the trunk.  Once files have been
  added or removed, you degenerate to the case where the .origin
  revisions (or even 1.1 revisions) of these files could have been added
  at different times and offering to calculate .origin is misleading at
  best.
 
  The only consistent way to do this is to tag everything after the
  import and diff against that tag.  This tag couldn't even really be
  automated, except in something like the import command, which imports
  a set of files at once and tags the set.
 
  .origin makes no sense.

 And furthermore, in the use case Frank mentioned, the commitid should
 now fulfill the need .origin was serving.

As I stated before, there are certainly several ways to achieve this. But all 
of them require more interaction than typing a single expression. To compare 
against a commitid, you need to know the commitid, and it probably requires 
to run cvs log before. To tag an import or add requires doing it _always_. If 
a file is added on a branch, and its contents hasn't been hacked from scratch 
but taken from somewhere else, it might again become interesting what has 
been changed between add and the current head of the branch.

Granted, usage of .origin would seldom mean much across multiple files, but 
still it has a specific meaning on single files, or a selection of files. All 
in all, I think the convenience of a single expression more than balances the 
chance of being misleading. However it might make sense to only allow .origin 
to be used at maximum on a selection of files, and prevent usage on 
directories with no filenames specified.

A more detailed description of the current .origin behavior will follow with 
my next patch ... probably later today?

Regards
Frank
-- 
- The LinCVS Team -
http://www.lincvs.com



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Recent checkins to lib/xgetcwd.c breaks Windows

[Jim Hyslop]

The recent checkin to lib/xgetcwd.c changes the implementation of 
xgetwd() from:

char *
xgetwd ()
{
  char *cwd;
  char *ret;
  unsigned path_max;
  errno = 0;
  path_max = (unsigned) PATH_MAX;
  path_max += 2;/* The getcwd docs say to do this. */
  cwd = xmalloc (path_max);
  errno = 0;
  while ((ret = getcwd (cwd, path_max)) == NULL  errno == ERANGE)
{
  path_max += PATH_INCR;
  cwd = xrealloc (cwd, path_max);
  errno = 0;
}
  if (ret == NULL)
{
  int save_errno = errno;
  free (cwd);
  errno = save_errno;
  return NULL;
}
  return cwd;
}
to:
char *
xgetcwd (void)
{
  char *cwd = getcwd (NULL, 0);
  if (! cwd  errno == ENOMEM)
xalloc_die ();
  return cwd;
}
While the new version is shorter, it doesn't work on Windows (Cygwin). 
It appears that Cygwin expects the parameter to getcwd() to be non-NULL. 
At least, 'getcwd()' always returns in the latest version of the file 
(trunk). Can we revert xgetcwd.c to its previous version? Why was it 
changed?

--
Jim

___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs