Re: [TopGit PATCH] hooks/pre-commit: check for cycles in dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2009/6/5 Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>:
> Hi Bert,
Hi, Uwe,

>
> On Thu, Jun 04, 2009 at 10:41:13PM +0200, Bert Wesarg wrote:
>> Only newly added dependencies needs to be considered.  For each of these deps
>> check if there is a path from this dep to the current HEAD.
>>
>> Use recursive_dep() for this task.  Even if recursive_dep() uses a DFS-like
>> traversal it will not run into an infty-loop if there would be a cycle, because
> I'm not sure how understandable this is.  After some thinking I
> understood DFS.  Up to now I thought infty is just the LaTeX macro name
> for "infinity", but apart of this, is this really the right term here?
> endless loop?
Yeah, 'endless loop' is the right term here.

>
>> recursive_dep() takes .topdeps only from committed trees.  And it is required
>> that the committed dependency graph is acyclic.
>
> I didn't check the implementation deeply.  But all in all I don't have
> the usual warm and fuzzy feeling about it.  What happens during a remote
> update if only the merged dependency graph has a cycle[1]?
I suspect the merge commit, which would introduce this cycle, will abort.

BTW: Do you have any infos or need help on your TopGit successor?

Bye,
Bert

>
> Best regards
> Uwe
>
> [1] The question is a bit theoretic because remote updating is broken
> here.  If you are my remote and changed a .topdep file, my update simply
> discards your change.
>
> --
> Pengutronix e.K.                              | Uwe Kleine-König            |
> Industrial Linux Solutions                    | http://www.pengutronix.de/  |
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]