You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2003/05/14 02:56:24 UTC
Re: svn commit: rev 5929 - trunk/subversion/libsvn_wc
On Tue, May 13, 2003 at 08:28:07PM -0500, sussman@tigris.org wrote:
>...
> @@ -776,6 +763,14 @@
> (SVN_ERR_WC_OBSTRUCTED_UPDATE, NULL,
> "failed to add dir '%s': \nobject of the same name is already "
> "scheduled for addition", path);
> +
> + /* Immediately create an entry for the new directory in the parent.
> + Note that the parent must already be either added or opened, and
> + thus it's in an 'incomplete' state just like the new dir. */
> + tmp_entry.kind = svn_node_dir;
> + SVN_ERR (svn_wc__entry_modify (adm_access, db->name, &tmp_entry,
> + SVN_WC__ENTRY_MODIFY_KIND,
> + TRUE /* immediate write */, pool));
Don't you want to set the 'incomplete' flag here?
Oh. This is in the parent dir, huh? The incomplete flag is only mentioned in
THIS_DIR ?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 5929 - trunk/subversion/libsvn_wc
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> On Tue, May 13, 2003 at 08:28:07PM -0500, sussman@tigris.org wrote:
> >...
> > @@ -776,6 +763,14 @@
> > (SVN_ERR_WC_OBSTRUCTED_UPDATE, NULL,
> > "failed to add dir '%s': \nobject of the same name is already "
> > "scheduled for addition", path);
> > +
> > + /* Immediately create an entry for the new directory in the parent.
> > + Note that the parent must already be either added or opened, and
> > + thus it's in an 'incomplete' state just like the new dir. */
> > + tmp_entry.kind = svn_node_dir;
> > + SVN_ERR (svn_wc__entry_modify (adm_access, db->name, &tmp_entry,
> > + SVN_WC__ENTRY_MODIFY_KIND,
> > + TRUE /* immediate write */, pool));
>
> Don't you want to set the 'incomplete' flag here?
>
> Oh. This is in the parent dir, huh? The incomplete flag is only mentioned in
> THIS_DIR ?
Yup. Our universal rule of entries files is: a parent directory's
pointer to a subdir is nothing but a name, a file-kind, and possibly a
schedule flag.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Repeatability Files
Posted by Jonathan Smith <jo...@members.limitless.org>.
In our project, we test the output's repeatability from each change to the
next. The ouput consists of maybe 10 meg. In order to facilitate
conflict resolution, I need to have these files available for the most
recent version of the code to compare my version with the conflicts
resolved against. As this output *can* be generated from the compiled
version of the code in the repository, this output, strictly speaking,
shouldn't be revision controlled.
For example:
repository has version n
I checkout version n
Harry commits version n+1
My change is repeatable
I update to version n+1 with my changes
I need the output of version n+1 to compare to, I only have version n
Recompiling version n+1 without my changes is virtually impossible without
a second checkout of the sourcecode.
My thought is, fine. Just commit the output files... store them in a
separate top level directory that can be disregarded; however, link them
in where they belong in the repository. I don't remember what this is
called, possibly externals, but I remember reading about it in the
documentation. But, thats about 20 lines of change simply by re-running
the program (time-date stamps) and hundreds of thousands if we actually
change the output. Can we reduce this with a meta data tag to specify to
only hold N revisions in history? I'd be agreeable to N=1, though i'd
prefer N=5 or N=10.
I'm sure that this is far, far, far easier than my last request.
I'm *really* starting to like the meta data. Power to the users!
j.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org