Re: [Monotone-devel] Re: cannot drop non-empty directory during branch update

[J Decker]

(true story)

Okay turns out they weren't products of the build.... (even though no
matter what they are, if you are developing a few bits of code in many
places reversion is crazy annoying.... )

What if ... I start a project, add a few base things that are
definatly in, but I'm adding a module that may or may not be good... I
don't want to commit it - cause it'll never go away... I don't want to
delete it - it's got a few ideas....

if the directory can't be droped it should be a warning, and the
update should continue....

(okay really the true story)
in the process of this if there are other files which can be dropped
it may indeed drop those... forcing one to do a mtn revert --missing,
mtn update (again) oh - another place needs to be cleaned... (find,
delete, delete the first again, cause it will cause afailure i not
manually cleaned) , mtn revert --missing, mtn update (oop damn, again,
another project changed slighly, someone commited into a directory
called sqllib instead of SQLlib, oh and a third one? they commited
into SqlLib, and can't create the directory causeit already exitsts,
can't delete the directory cause it's not empty... okay screw this ...

mtn head, <snip revision> edit _MTN/revision <paste>, edit
_MTN/options, fix branch

mtn revert .
and whoa everthing updates (except now I lose those changes in yet
other projects)


maybe noone has any projects that include 20 libraries and 8
programs... everyone writes one little application and calls it good -
like mtn - that's just one utility, which when working on certain
things requires bouncing to many other related stuff - what if I were
a boost maintainer too and found a really slick way to optimize
something...




On 9/18/07, Zack Weinberg <address@hidden> wrote:
> On 9/18/07, William Uther <address@hidden> wrote:
> > I'm not sure this makes a real difference.  Either you want to re-
> > generate them or you don't.  If you don't want to re-generate them
> > then you should add them.
>
> I have nothing in particular to add to the rest of the discussion, but
> I want to point out that there are legitimate use cases for putting
> generated files into version control.  The one I know about is when
> the source changes rarely *and* you need an unusual tool to do the
> regeneration.  For example, there's this thing called AutoGen (has
> absolutely nothing in common with automake or autoconf, except that I
> believe the name was inspired by them) which is used to generate
> several files inside the GCC repository, such as the 'fixincludes'
> script.  The script doesn't change often and we don't want to make
> people have the tool.
>
> It occurs to me that Monotone could do nice things for this scenario
> with a specialized cert on the derivative file, identifying the
> source(s) by file ID and content hash.  This would have two effects:
> if the source file is being checked in and the derivative file isn't,
> the commit is rejected; and on checkout we somehow ensure that the
> last modification time of the derivative file is later than the last
> modification time of the source files.  (GCC has a horrible
> post-checkout script you're supposed to run to do this.  It would be
> *really nice* if it happened automatically.)
>
> zw
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>